ttk::style configure questions
Mark Roseman
Q: What do the ttk::style configure options apply to?
If my style has three elements in it, and I say "ttk::style configure
style -option value", do the configuration options get passed down to
all of the three elements (testing to see if the element supports the
option or not)? To the first element that matches the option?
In other words, are the style options entirely a front end to the
element options?
Q: How can I configure particular elements of a style?
I've seen the one example floating around that does a style::configure
on "TLabelframe.Label" which does change the colors on just that part of
a labelframe (where as doing the style::configure on just "TLabelframe"
would change the background color of all elements in the style).
Where does the ".Label" come from? If I do "ttk::style layout
TLabelframe" to list the elements that are part of the style, all I get
is a single element, "Labelframe.border".
Mark
Pat Thoyts
>And here I thought I was doing so well understanding things...
>
>Q: What do the ttk::style configure options apply to?
>
>If my style has three elements in it, and I say "ttk::style configure
>style -option value", do the configuration options get passed down to
>all of the three elements (testing to see if the element supports the
>option or not)? To the first element that matches the option?
>
>In other words, are the style options entirely a front end to the
>element options?
Yes. Widget level options are configured as before. But elements are
flyweight classes - there is no storage for configuration options in
an element instance so the options are stored in the theme using the
element name or a more specific style.elementname key. The option will
be accessed when the element either calculates its geometry or draws
itself.
>Q: How can I configure particular elements of a style?
>
>I've seen the one example floating around that does a style::configure
>on "TLabelframe.Label" which does change the colors on just that part of
>a labelframe (where as doing the style::configure on just "TLabelframe"
>would change the background color of all elements in the style).
You provide more specific naming using style.element
See below for a coloured button example.
>Where does the ".Label" come from? If I do "ttk::style layout
>TLabelframe" to list the elements that are part of the style, all I get
>is a single element, "Labelframe.border".
Some of the composite widgets currently look for specifically named
sub-layouts. The TNotebook is another one - the tabs are defined as
TNotebook.Tab. If this isn't documented - it ought to be but I believe
the plan is to change this so that these 'known names' will not be
required.
Example of a coloured button:
# By calling this on <<ThemeChanged>> we can define it for all themes used.
proc PlainButtonInit {} {
# Import the 'default' theme button border element (can be coloured).
catch {
ttk::style element create plain.border from default
}
# Re-create the 'default' theme button layout and import the theme
# configuration settings for the TButton style.
# Note: we are keeping the current theme's focus and label
# elements.
ttk::style layout Plain.Button {
Plain.Button.plain.border -sticky nswe -border 0 -children {
Plain.Button.focus -sticky nswe -children {
Plain.Button.padding -sticky nswe -children {
Plain.Button.label -sticky nswe
}
}
}
}
eval [list ttk::style configure Plain.Button] \
[ttk::style theme settings default {ttk::style configure TButton}] \
-background SteelBlue
eval [list ttk::style map Plain.Button] \
[ttk::style theme settings default {ttk::style map TButton}] \
[list -background {active LightSteelBlue}]
}
--
Pat Thoyts http://www.patthoyts.tk/
To reply, rot13 the return address or read the X-Address header.
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
Donal K. Fellows
> eval [list ttk::style configure Plain.Button] \
> [ttk::style theme settings default {ttk::style configure TButton}] \
> -background SteelBlue
> eval [list ttk::style map Plain.Button] \
> [ttk::style theme settings default {ttk::style map TButton}] \
> [list -background {active LightSteelBlue}]
These are absolutely prime candidates for simplifying with expansion
syntax, like this:
ttk::style configure Plain.Button \
{*}[ttk::style theme settings default {ttk::style configure
TButton}] \
-background SteelBlue
ttk::style map Plain.Button \
{*}[ttk::style theme settings default {ttk::style map TButton}]
\
-background {active LightSteelBlue}
Indeed, expansion syntax is exactly for this sort of use, and exists
to prevent problems with remembering to get everything quoted right.
Donal.
Pat Thoyts
>Indeed, expansion syntax is exactly for this sort of use, and exists
>to prevent problems with remembering to get everything quoted right.
And sometimes we have code written with 8.4
Donal K. Fellows
> And sometimes we have code written with 8.4
Fuddy-duddy. ;-)
Donal.
Mark Roseman
> Yes. Widget level options are configured as before. But elements are
> flyweight classes - there is no storage for configuration options in
> an element instance so the options are stored in the theme using the
> element name or a more specific style.elementname key. The option will
> be accessed when the element either calculates its geometry or draws
> itself.
Pat, thanks, that's a big help.
As for the "known names" to refer to elements within a style, I can't
locate any documentation for it. Would it be safe to say that this is
one of those areas that is likely to go through some additional
refinement?
But at the moment, the elements within particular widget-specific styles
that can be introspected aren't documented or introspectable, but
perhaps intuitable, although likely to change? :-)
Another question... if I do:
ttk::style configure TButton.boguspartthatisnotthere -font red
It happily does nothing, but provides no error message. When I was
first trying to figure out what was valid or not, this didn't help
matters much. Is there a rationale for this not giving an error?
Once I'm a bit further through, I'll get you a draft of the styles
documentation I'm trying to write for www.tkdocs.com.
Thanks again
Mark
Pat Thoyts
>As for the "known names" to refer to elements within a style, I can't
>locate any documentation for it. Would it be safe to say that this is
>one of those areas that is likely to go through some additional
>refinement?
Actually a recent commit shows that this will indeed be changing:
2008-05-23 Joe English <jeng...@users.sourceforge.net>
* doc/ttk_treeview.n, generic/ttk/ttkTreeview.c,
[snip]
Added [$tv identify region], [$tv identify element],
and [$tv identify item] subcommands. Simplified
bindings. Added [$tv tag has] subcommand. Tag-related
display improvements; setting a tag -background or -foreground
no longer overrides selection feedback.
[snip]
Don't need separate 'Item', 'Cell', and 'Row' style
settings anymore, only the base "Treeview" style is used.
So its been done to treeview and I know Joe talked about having an
extended [identify] for notebook.
>But at the moment, the elements within particular widget-specific styles
>that can be introspected aren't documented or introspectable, but
>perhaps intuitable, although likely to change? :-)
>
>Another question... if I do:
> ttk::style configure TButton.boguspartthatisnotthere -font red
>
>It happily does nothing, but provides no error message. When I was
>first trying to figure out what was valid or not, this didn't help
>matters much. Is there a rationale for this not giving an error?
Yep. Because you might have a theme that does implement that element
or the theme may do so. Styles are not fixed. For instance in the XP
theme there is a Button.button element that does not exist in the
default theme.
Possibly as the element configuration is per-theme, it could be done
that we insist that element configuraton is loaded once the elements
are defined. I suspect this has evolved from the options database
stuff - where you can also define settings for things that dont
exist.
Joe English
>
> As for the "known names" to refer to elements within a style, I can't
> locate any documentation for it. Would it be safe to say that this is
> one of those areas that is likely to go through some additional
> refinement?
Yes. The collection of elements and what options they support
evolved in a mostly ad-hoc fashion, trying to figure out which
approach worked best. Consequently there's not much consistency
across themes. (This is also a big part of the reason why there's
no good answer to "how do I make my color scheme match the current
theme colors?" yet.)
The plan has been to reorganize things to make them more
consistent and rational, but that effort is pretty much
stalled out right now. Draft document here:
<URL: http://tktable.sourceforge.net/tile/doc/elements.html >
> But at the moment, the elements within particular widget-specific styles
> that can be introspected aren't documented or introspectable, but
> perhaps intuitable, although likely to change? :-)
You can extract the elements referenced by a particular -style
out of [ttk::style layout $style], and you can find out
what elements are defined in the current theme with
[ttk::style element names].
> Another question... if I do:
> ttk::style configure TButton.boguspartthatisnotthere -font red
>
> It happily does nothing, but provides no error message. When I was
> first trying to figure out what was valid or not, this didn't help
> matters much. Is there a rationale for this not giving an error?
Yep. 'Cause somebody might later define and use a derived
style that does have that part.
--JE