Re: Tile widgets: using "cget"

Bryan Oakley wrote:

>Hmmm. So you're advocating that if I detect that colors have changed
>(eg: user selected a different theme) I must do something like:
>
> if {$theme_changed} {
> <1 save any custom changes I've made to the option database>
> <2 ttk::apply_theme_to_option_database>
> <3 fetch color definitions from the option database>
> <4 restore my custom changes>
> .myWidget configure -background <fetched color>
> }


That would be one approach; it's sort of how tk_setPalette works,
and the Tile theme => core option mapping code has a little bit of
support for doing just this. True, it's full of pitfalls and has
lots of failure cases, but I really can't think of any other way to
do it that's any easier or more reliable.

>That seems rather cumbersome.

Agreed. But it wouldn't get any better with the approach you
suggest below -- the only thing that would change is the mechanism
for fetching color definitions (and fonts, and borderwidth settings,
et cetera.)

>Still, that seems like a valid scenario if I have things configured the
>way I want and simply want to get the name of the background used by
>ttk::entry. Besides copying attributes from a themed widget to a
>non-themed widget, maybe I just want to stick the value in a listbox in
>a dialog.

OK, but the thing is: a [ttk::entry] widget doesn't *know*
what its background color is; only the theme does. For some
widgets in some themes, that's not even a sensible question
to ask of a widget, or of the widget's style: TButton on
Windows XP and TFrame on OSX don't even *have* a -background,
for example.

Right now there's no reliable way to get that information out
of the theme, either, but long-term that'll be the place to look.

>It seems to me that if you have the ability to populate the option
>database from the theme, it should be possible to write a procedure to
>extract a subset of that information without having to get the option db
>involved.

Note that Tile doesn't have that ability yet -- the main thing
that's missing is that themes will have to define settings appropriate
for all the core widgets in addition to defining how all the
Tile widgets look. Once that's there, it'll be in a well-known
place -- most likely the option database -- but it's not there yet.

>It's not the end of the world and you certainly have a better handle on
>the difficulty of the problem than I do, but I'll stick to my guns in
>thinking a little more introspection would be useful.

Recent Tile releases do have some style database introspection
features -- but the information you want to pull out of it
simply isn't there, at least not reliably. Tile theme definitions
currently specify how tile widgets should look; they don't say
anything about how core widgets should look.


--Joe English
.

Quantcast