[Tile-dev] Re: changing the bg of just one tbutton?

[Joe E. <jen...@fl...>]

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