Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow interface plug-ins to customize a few properties #363

Merged
6 commits merged into from Jun 10, 2011
Merged

Allow interface plug-ins to customize a few properties #363

6 commits merged into from Jun 10, 2011

Conversation

skurfer
Copy link
Member

@skurfer skurfer commented Jun 8, 2011

This change simply allows interfaces to alter some cosmetic details without subclassing/duplicating huge sections of the core application. I’m sure there are a lot of other things we could expose to interface developers, but it’s a start. (These are mainly the things I needed for the new interface I’m working on.)

Specifically, an interface plug-in can now change

  • the font used for object names
  • the font used for descriptions (that appear under the name)
  • the font used for the text entry panel
  • the color of text in the text entry panel
  • the radius for the rounded corners of each pane

In all cases, doing nothing (which is what all existing interfaces will do) leaves you with the same value that would have previously been hard-coded.

@ghost
Copy link

ghost commented Jun 10, 2011

looks good to me.

ghost pushed a commit that referenced this pull request Jun 10, 2011
Allow interface plug-ins to customize a few properties
@ghost ghost merged commit 2d07642 into quicksilver:master Jun 10, 2011
@ghost
Copy link

ghost commented Jun 10, 2011

one nitpick: on the mini-bezel and menu interfaces at least, nameFont should be size 11 by default. i'm not sure if it's just those interfaces that have the wrong font size, do other interfaces use size 12 for nameFont by default?

@skurfer
Copy link
Member Author

skurfer commented Jun 10, 2011

I thought the text in the stock interfaces seemed a tiny bit larger, but wasn’t sure if I was imagining things. Look around line 88 of QSObjectCell.m. I just changed it from “12” to “12.0” since that method expects a float.

My guess is that line was being silently ignored when it passed an int. Now that I’ve changed it, it’s “working”, but it’s not necessarily doing what we want. :)

Because those interfaces require smaller text, I think they should explicitly say so with a call to setFont on each of the three panes, rather than making assumptions about application defaults. (The setFont method has always been available, so such a change should be backward compatible with older versions of Quicksilver.) What do you think?

@ghost
Copy link

ghost commented Jun 10, 2011

I just changed it from “12” to “12.0” since that method expects a float.

but in the old QSObjectCell.m:446, [[self font] pointSize] always has 1 subtracted from it before it's passed into the nameAttributes dictionary, and as that isn't done when the dictionary's being created any more, it seems that nameFont should default to size 11.

My guess is that line was being silently ignored when it passed an int.

i'm pretty sure the compiler can automatically convert from an int to a float.

@skurfer
Copy link
Member Author

skurfer commented Jun 10, 2011

Ah, true. That required knowing the height of cellFrame which isn’t available in the initTextCell method.

I suppose we could initialize nameFont and detailsFont to nil and then if they aren’t set by the interface plug-in, use the old behavior to define them. Sound good?

But I still say that if an interface depends on a certain size to work properly, it needs to specify that size.

i'm pretty sure the compiler can automatically convert from an int to a float.

Well, OK probably, but think of the overhead! I only have 2 cores with 2 threads on each. ;)

@ghost
Copy link

ghost commented Jun 10, 2011

I suppose we could initialize nameFont and detailsFont to nil and then if they aren’t set by the interface plug-in, use the old behavior to define them. Sound good?

yep, sounds like a much better way to handle it. it's just that there are probably going to be a lot of people using old versions of interface plugins for a while, at least until in-app plugin updating is done, so backwards-compatibility would be a good idea for now. you are right though, interface plugins should specify font sizes from now on.

This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant