Tile theme engine

I have a few questions and suggestions related to the tile widget set.

1. Several widget options may have the value "".  For example, the
-font, -background, and -foreground options for a ttk::label have
the default value "", which may also be set explicitly.  The query
(by using cget or configure) returns the same empty string.  This is
OK, but how can one retrieve the font, background, or foreground
color of the widget if the corresponding configuration option has
the value ""?  There are many cases where this is needed,
especially in Tcl-only widget libraries.  As for tile version 0.5,
I couldn't find any way to get this info.  If currently there is
indeed no support for it, I would like to suggest the tile developer
team to provide a solution to this problem in one of the subsequent
releases.

2. The "style theme use themeName" command can be used to change the
theme.  But I haven't found any way to query the current theme.  I
think, this should be made possible, too.

3. The tile theme engine has introduced several incompatibilities.
Some of them are justified, some others could have been avoided.
For example, the -padx and -pady options have been merged into a
single -padding option (whose value is a list of up to 4 elements).
IMHO, it would have been better to keep the -padx and -pady options
and extend them in the same way as it was done by D. Richard Hipp
for the pack and grid geometry managers (where these options now
accept either a number or a list of two numbers as values).  The
fact that the -padx and -pady options continue to be supported for
compatibility purposes but their values are ignored, doesn't make
the situation better; in contrary, it will give raise to a lot of
confusion.  If the tile developers stick to the new -padding
option, then they should either extend the old -padx and -pady
options (like in pack and grid) and tie them to the new -padding
option, or should completely eliminate them from the tile widgets.

4. Similarly, IMHO the current handling of the -state compatibility
option is another source of confusion.  It should either be
eliminated or closely tied to the new state and instate widget
commands.

I hope, my remarks above won't hurt anybody.  They are meant as
positive criticism, aimed to help the tile developer team, which is
doing a really excellent work.

--
Csaba Nemethi   http://www.nemethi.de   mailto:csaba.nemethi@t-online.de

Csaba Nemethi wrote:
> I have a few questions and suggestions related to the tile widget set.

The best place for dev issues might be the tktable-tile-dev
mailing list at SF.

> 1. Several widget options may have the value "".  For example, the
>    -font, -background, and -foreground options for a ttk::label have
>    the default value "", which may also be set explicitly.  The query
>    (by using cget or configure) returns the same empty string.  This is
>    OK, but how can one retrieve the font, background, or foreground
>    color of the widget if the corresponding configuration option has
>    the value ""?  There are many cases where this is needed,

I'm not sure I get the problem ... but I think it's a known
feature.  Setting and getting works fine:

(Tcl) 51 % package require tile
0.5
(Tcl) 52 % ttk::label .l -font Courier
.l
(Tcl) 53 % .l cget -font
Courier

and the reason they start out as {} is because they inherit
from the theme.

> 2. The "style theme use themeName" command can be used to change the
>    theme.  But I haven't found any way to query the current theme.  I
>    think, this should be made possible, too.

Well, currently this gives it to you, but I think that the
themeName above should be made optional

(Tcl) 62 % set ::tile::currentTheme
xpnative

> 3. The tile theme engine has introduced several incompatibilities.
>    Some of them are justified, some others could have been avoided.
>    For example, the -padx and -pady options have been merged into a
>    single -padding option (whose value is a list of up to 4 elements).
>    IMHO, it would have been better to keep the -padx and -pady options
>    and extend them in the same way as it was done by D. Richard Hipp
>    for the pack and grid geometry managers (where these options now
>    accept either a number or a list of two numbers as values).  The

I disagree.  It was wrong from the start to ever have these
as separate options.  This was done because, prior to Tcl
objects, it was easier at the config level that each -opt
represented a single value.  Richard went with the existing
options when enhancing them.  However, a simpler -pad that
takes 4 options is "cleaner" IMO.

>    fact that the -padx and -pady options continue to be supported for
>    compatibility purposes but their values are ignored, doesn't make
>    the situation better; in contrary, it will give raise to a lot of
>    confusion.  If the tile developers stick to the new -padding
>    option, then they should either extend the old -padx and -pady
>    options (like in pack and grid) and tie them to the new -padding
>    option, or should completely eliminate them from the tile widgets.

In the future they will be completely eliminated.  They
exist for pseudo-compatability only at this point.

> 4. Similarly, IMHO the current handling of the -state compatibility
>    option is another source of confusion.  It should either be
>    eliminated or closely tied to the new state and instate widget
>    commands.

Yes, this is possibly an area that could be improved, but
then again, this is an opportunity to improve the current
widget set without remaking known issues.

> I hope, my remarks above won't hurt anybody.  They are meant as
> positive criticism, aimed to help the tile developer team, which is
> doing a really excellent work.

Constructive criticism is always appreciated.  Since tile
and related items are going to start getting into 8.5 in
the next few months, now is the time to explore and comment
on the API.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

Jeff Hobbs wrote:
> Csaba Nemethi wrote:
> 
>
>
> I'm not sure I get the problem ... but I think it's a known
> feature.  Setting and getting works fine:
>
> (Tcl) 51 % package require tile
> 0.5
> (Tcl) 52 % ttk::label .l -font Courier
> ..l
> (Tcl) 53 % .l cget -font
> Courier
>
> and the reason they start out as {} is because they inherit
> from the theme.
>

It is true that getting the value of an *explicitly* set option works
as expected.  But how can I get the font of .l if it was created
*without* an explicitly specified font value?  In that case,

.l cget -font

returns an empty string.  The same holds true after performing

.l configure -font ""

The last command just resets the label's font to the default one.  But
how can I get the default label font (inherited from the theme)?

--
Csaba Nemethi   http://www.nemethi.de   mailto:csaba.nemethi@t-online.de

"Jeff Hobbs" <jeffh@removethis.activestate.com> wrote in message
news:41B370DA.4060706@removethis.activestate.com...
> Csaba Nemethi wrote: 
>
> The best place for dev issues might be the tktable-tile-dev
> mailing list at SF.
> 
>
> I'm not sure I get the problem ... but I think it's a known
> feature.  Setting and getting works fine:
>
> (Tcl) 51 % package require tile
> 0.5
> (Tcl) 52 % ttk::label .l -font Courier
> .l
> (Tcl) 53 % .l cget -font
> Courier
>
> and the reason they start out as {} is because they inherit
> from the theme.
> 
>
> Well, currently this gives it to you, but I think that the
> themeName above should be made optional
>
> (Tcl) 62 % set ::tile::currentTheme
> xpnative
> 
>
> I disagree.  It was wrong from the start to ever have these
> as separate options.  This was done because, prior to Tcl
> objects, it was easier at the config level that each -opt
> represented a single value.  Richard went with the existing
> options when enhancing them.  However, a simpler -pad that
> takes 4 options is "cleaner" IMO.
> 
>
> In the future they will be completely eliminated.  They
> exist for pseudo-compatability only at this point.
>
Yikes! I hope this approach toward compatibility doesn't apply to all
of tile. I'm not sure separate x/y pad options are better or worse than a
single one. It doesn't seem  at all obvious. But I do know that it's much
easier
mentally  checking a 2 item list as opposed to a 4 item list.  Please keep
compatibility for such basics. If the -padx -pady did not work anymore that
would
mean hundreds of code mods in just the small group of projects I have in use
and/or
development.
Roy

Roy Terry wrote:
> Jeff Hobbs wrote:
> 
>
> Yikes! I hope this approach toward compatibility doesn't apply to all of t
ile.
> I'm not sure separate x/y pad options are better or worse than a single on
e. It
> doesn't seem  at all obvious. But I do know that it's much easier mentally
> checking a 2 item list as opposed to a 4 item list.  Please keep compatibi
lity
> for such basics. If the -padx -pady did not work anymore that would mean
> hundreds of code mods in just the small group of projects I have in use an
d/or
> development.

If you are using -padx / -pady that often for individual widgets,
then you aren't using them right ;).

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

Roy Terry wrote:
>
> Yikes! I hope this approach toward compatibility doesn't apply to all
> of tile. I'm not sure separate x/y pad options are better or worse than a
> single one. It doesn't seem  at all obvious. But I do know that it's much
> easier
> mentally  checking a 2 item list as opposed to a 4 item list.  Please keep
> compatibility for such basics. If the -padx -pady did not work anymore tha
t
> would
> mean hundreds of code mods in just the small group of projects I have in u
se
> and/or
> development.
> Roy
>
>

It is my opinion, too, that it is easier to use

-padx {left right} -pady {top bottom}

than

-padding {left top right bottom}

even if the last list may have fewer than 4 elements.  In addition (and
this is maybe more important), the way chosen by D. Richard Hipp for
pack and grid is fully compatible with the classical approach.

But my main problem (to which I haven't got any answer up to now) is
that I need a way to query the font, background, and foreground colors
of a widget for which these options were not specified explicitly.
That is, if I simply write

ttk::label .l

then I can't get the widget's font, because

.l cget -font

returns an empty string and

.l configure -font

returns

-font font Font {} {}

In my opinion this is not satisfactory.  It might be OK (and consistent)
to get an empty string as result, also because (unlike for the classical
Tk widgets) it is allowed to reset the widget's font to the default one
(inherited from the current theme) by writing

.l configure -font ""

But then we need some other command that returns the widget's default
font, colors, and other configuration options.  This is really
important for many mega-widget packages, if we want to replace their
components with tile widgets.

--
Csaba Nemethi   http://www.nemethi.de   mailto:csaba.nemethi@t-online.de

Csaba Nemethi wrote:
> But then we need some other command that returns the widget's default
> font, colors, and other configuration options.

Agreed, though what's needed is really a way of querying what a
particular component of a style is using. And there's no guarantee that
that will actually be helpful in the case of OS-defined styles. :^/

> This is really
> important for many mega-widget packages, if we want to replace their
> components with tile widgets.

Now this bit I don't buy. Why does a megawidget package need to query
the fonts of things? I'd understand defining its own styles and things
like that, but surely the goal would be for the megawidgets to let the
style engine look after the look of things? I know this is a big change
from specifying everything to specifying virtually nothing, but it's a
good thing overall.

Donal.

Donal K. Fellows wrote:
> Csaba Nemethi wrote:
> 
>
>
> Agreed, though what's needed is really a way of querying what a
> particular component of a style is using. And there's no guarantee that
> that will actually be helpful in the case of OS-defined styles. :^/
> 
>
>
> Now this bit I don't buy. Why does a megawidget package need to query
> the fonts of things? I'd understand defining its own styles and things
> like that, but surely the goal would be for the megawidgets to let the
> style engine look after the look of things? I know this is a big change
> from specifying everything to specifying virtually nothing, but it's a
> good thing overall.
>
> Donal.

I can't agree with you in this respect.  For example, my Tablelist
package implements a mega-widget whose column titles are displayed in
label widgets.  The width of each of them may be static or dynamic.  In
the first case I need the label's font in order to be able to determine
what part of the columns's title will fit into the label (and replace
the rest with an ellipsis).  In the second case I need the font, too
(for book-keeping purposes), although this case could probably be
handled also without explicit knowledge of the label's font..

Likewise, the up/down-arrow indicating the sorting order is placed in
a canvas, which in turn is placed in the label corresponding to the
column by which the items were sorted.  I had good reasons for using
this approach instead of compound labels.  Now, I must set the
background color of this canvas to that of the label, because otherwise
the arrow would appear embedded in a rectangle with a different
backgriund color.

The above are just two examples, and I am quite sure that these are not
the only ones where a mega-widget needs various informations about its
components.  To know that the font or color is just the style-specific
default, is not enough.  Of course, I could be very restrictive in this
respect, setting some pre-defined values for these options and
rejecting empty strings as option values.  This would be, however, not
compatible with the idea used in the tile library, that the empty
string is simply viewed as a place-holder for the default value of the
font, background color, etc.

--
Csaba Nemethi   http://www.nemethi.de   mailto:csaba.nemethi@t-online.de

I too am rather surprised by tile's approach (or lack thereof) to
backwards compatibility -- especially given Tcl, Tk's focus on almost
extreme efforts at backwards compatibility.

Lots of things in tile are different to Tk for not particularly
important reasons, and they would be far better off being the same,
IMHO. I'm trying to use tile in an application, and I find I need to
add a _lot_ of code to deal with all these differences.

The most important things I think need to be fixed in tile (beyond
these needless incompatibilities) are:

(1) Allow individual widget configuration options to over-ride the
style -- for example -background, -wraplength, etc.  Tile currently
takes the approach that basically _everything_ is in the style -- i.e.
everything is look and feel. I think that's wrong (or if not wrong,
then much too limiting for a dynamic language like Tk).  Of course this
doesn't mean that every widget is going to be configuring these, but
the point is that _some_ widgets will, and sometimes in systematic
ways. If you have to define yet-another-style for each time you want to
make a tiny configuration change, Tk's ease of use has just disappeared
and you might as well be using some other graphical toolkit. And you
can't mix Tk and Tile widgets because they look totally different.

(2) You can't change existing style 'layouts'. They are fixed and you
get an error when you try to redefine them. Again, that's no good for
something dynamic like Tk.

Vince.

<vince.darley@eurobios.com> wrote
>
> The most important things I think need to be fixed in tile
> (beyond these needless incompatibilities) are:
>
> (1) Allow individual widget configuration options to
> over-ride the style -- for example -background, -
> wraplength, etc.
...
> (2) You can't change existing style 'layouts'. They are
> fixed and you get an error when you try to redefine them.
> Again, that's no good for something dynamic like Tk.


I understand your points, Vince.  But I disagree.

(1)  Building a good looking GUI with less code is a Good Thing(tm).
I don't want to have to define -activebackground.  The only reason I
can think of that I would want that much control is if the toolkit or
the platform was somehow inadequate.  And some platforms have been
pretty shaky.  HP-UX with CDE is kind of an icky thing, and you need
to set some Tk options to get applications to look right.  But if the
toolkit draws a modern, usable, good looking GUI, then I don't want to
fuss with it.

Further, if you've got all those options, then somebody (you, me, or
somebody down the hall) is going to make a bisque application with
great big green and red buttons with -borderwidth scaled according to
the amount of CPU time required to perform the associated command.
Those make my eyes hurt.  They are a Bad Thing(tm).

(2)  I don't understand what you mean by changing layouts.  I have a
tile-based application, and when I call [tile::setTheme], all the tile
widgets change.  (The BLT graph doesn't change, but them's the
breaks.)

Bob
--
Bob Techentin                   techentin.robert@NOSPAMmayo.edu
Mayo Foundation                                 (507) 538-5495
200 First St. SW                            FAX (507) 284-9171
Rochester MN, 55901  USA            http://www.mayo.edu/sppdg/