|
From: Joe E. <jen...@fl...> - 2004-08-27 19:42:35
|
Jeff Hobbs wrote:
> So I was playing with trying to just -style one item (or one
> class of items ... no matter). IOW, one button, entry or
> label that just has its own bg.
>
> I looked at the Toolbutton stuff, which is really trying to
> change the behavior,
[ An aside: the Toolbutton actually *doesn't* change the behavior,
only the dynamic appearance. This is pretty cool, IMHO -- the exact
same set of class bindings works for normal and toolbar-style
buttons, on all platforms, plus checkbuttons and radiobuttons too.
For these widgets the look is completely decoupled from the feel.
But anyway ... ]
> but seems to be the only example. It is
> overly complex for my situation, but seems to be the only
> solution. You can't seem to create another style without
> creating a full layout for it.
The theme engine has some fallback rules that might help with this.
For example, you could say:
style default Blue.TButton -background blue
tbutton .bluebutton -style Blue.TButton
".bluebutton" will inherit all of the defaults and dynamic
settings from the "TButton" style, with default -background blue
overriding. This won't work at present since layouts aren't
inherited (they probably should be...), so as you noted you'll
also need to define a layout for "Blue.TButton".
Also note that in some themes, XP and Aqua in particular,
the (elements used in the) TButton style don't even have
a -background option, so this wouldn't have an effect there.
It might be useful to define a CustomButton widget, possibly
with "real" -background, -foreground, -borderwidth, etc., options
to support UIs with lots of one-off button styles.
A related issue: there are a few widgets (basically all of the
ones with an "-orient" option) that don't support custom -styles,
since they pick a layout/style dynamically based on other widget
options. Not sure what to do about that -- probably the right
solution is to let "-style" override the default as usual,
with the caveat to the user that the layout had better match
the selected orientation.
> At first I thought 'style theme create ... -parent' was what
> I wanted, until it set in that "theme create" really means
> theme create, not style create. I think that tile will need
> to support inherited styles where you just change a few
> elements, or it will be hard to introduce to a number of
> applications that styled one or two widgets slightly
> different from the standard options to get just the right
> effect for their app.
I think the current fallback scheme is basically on the right track,
but it's not well-documented, not completely thought-out, and not
very consistent right now. Element names, layouts, defaults, and
dynamic settings all have their own fallback chaining rules,
which can follow the name hierarchy ("a.b.c" -> "b.c" -> "c"),
the theme -parent hierarchy (xpnative -> winnative -> alt -> default),
or both. Pat and I have changed the fallback rules three or four
times already and they're still Not Quite Right. This use case
in particular isn't supported very well.
--Joe English
|