Changes coming to Cappuccino: text shadows, themes, and more
Francisco Tolmasky
might as well bring it up in its own thread to get some opinions.
Basically, we're trying to make it a lot easier to make controls and
to make them customizable. You can take a look at how this is coming
along on my branch here: http://github.com/tolmasky/cappuccino/tree/master
. It is still quite dynamic and not very stable, but it should be
ready for commit into the master sometime this coming week.
The first step to do this was to completely revamp the text engine,
which we've done with the new internal _CPImageAndTextView which will
be replacing _CPImageAndTitleView. This class fully supports fonts,
horizontal-alignment, vertical-alignment (of images and text), and
text-shadows, on every browser. This means that pretty soon you'll be
able to use things like text shadows on every control that shows text.
// DISPLAY PROPERTIES
The next step was to make it so that classes could more easily be
given custom styles without subclassing. For this, we've created the
new "setVALUE:forControlState:" methods, which allow you set display
properties for certain states of the control. For example, if you had
a button, you might do the following:
[myButton setBezelColor:myNormalColor];
[myButton setBezelColor:myHighlightedColor
forControlState:CPControlStateHighlighted];
[myButton setBezelColor:myDisabledColor
forControlState:CPControlStateDisabled];
[myButton setTextColor:[CPColor blackColor]];
[myButton setTextColor:[CPColor grayColor]
orControlState:CPControlStateDisabled];
// etc.
Just about all display properties for our controls are now "stated".
The upside to this is that you can create very complex behavior
without subclassing, but the downside is an explosion of API, for
every display property, we now have:
- (void)setVALUE:forControlState: (setter)
- (id)VALUEforControlState: (getter)
- (id)VALUE (getter for the "normal" case)
- (id)currentVALUE (getter for whatever the state is currently, so
this would return the "disabled" bezel color if the control is
currently disabled)
One alternative to this would be to use keys, so you'd have something
like
- (void)setValue:forKey:controlState:
- (id)valueForKey:controlState:
- (id)valueForKey:
- (id)currentValueForKey:
The tradeoff here is that you drastically reduce API (just 4 new
methods, vs 4 new methods per display property), but lose the explicit
nature of before. For example, the docs would never show
setBezelColor:forControlState:, they'd just have to mention that
CPButton adds the "bezel-color" key. Anyone have preferences in this
regard?
// THEMES
There are a number of other changes when it comes to customizability
as well, but the last big change is that we are incorporating themes.
There will be a new CPTheme class that encapsulates all these display
states, and you'd use it something like this:
[myButton setTheme:aTheme];
By default, views use [CPTheme defaultTheme], which you can set with
setDefaultTheme:. You can "extract" themes from views by calling -
themedValues on them. So, if you've created an application with lots
of themed views, you can use steam build-theme to "extract" a theme
from it. Theme files are full-fledged bundles, which means they
include all their images and any other resource you might want
(sounds, cibs, etc). The default theme is "inlined" into AppKit so as
to not require a separate download.
Leif Singer
> The tradeoff here is that you drastically reduce API (just 4 new
> methods, vs 4 new methods per display property), but lose the explicit
> nature of before. For example, the docs would never show
> setBezelColor:forControlState:, they'd just have to mention that
> CPButton adds the "bezel-color" key. Anyone have preferences in this
> regard?
I'd prefer the latter with keys for the properties. It just seems less
wordy to develop with, and easier to extend. Also, I don't think that
an API like that would be *too* generic, it's already pretty
specialized in that it deals with control states.
It would make sense to find the CPBezelColor key in the API docs,
then. Each control could have a table with all its property keys and
their possible states. For each key, I'd like to know the accepted
class as well (CPTextField may be in the following states: ... For
each of these states, you may set these properties: CPTextColor
(CPColor), CPBackgroundColor (CPColor), ... ).
> // THEMES
> By default, views use [CPTheme defaultTheme], which you can set with
> setDefaultTheme:. You can "extract" themes from views by calling -
> themedValues on them. So, if you've created an application with lots
> of themed views, you can use steam build-theme to "extract" a theme
> from it. Theme files are full-fledged bundles, which means they
> include all their images and any other resource you might want
> (sounds, cibs, etc). The default theme is "inlined" into AppKit so as
> to not require a separate download.
Sounds great. As long as I can ignore themes and only need to
acknowledge their existence when I want to use them, I'm fine. A
section on cappuccino.org with a few nice and complete themes would
seem nice then.
-- Leif