Tcl - Tile theme engine

Author

Tile theme engine

Csaba Nemethi

2004-12-07, 4:19 am

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

Jeff Hobbs

2004-12-07, 4:19 am

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

Csaba Nemethi

2004-12-07, 4:19 am

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

Roy Terry

2004-12-07, 4:19 am

"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

Jeff Hobbs

2004-12-07, 4:19 am

Roy Terry wrote:
> Jeff Hobbs 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 that would mean
> hundreds of code mods in just the small group of projects I have in use and/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

Csaba Nemethi

2004-12-07, 4:19 am

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 that
> would
> mean hundreds of code mods in just the small group of projects I have in use
> 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

Donal K. Fellows

2004-12-07, 4:19 am

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.

Csaba Nemethi

2004-12-07, 4:19 am

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

vince.darley@eurobios.com

2004-12-07, 4:19 am

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.

Bob Techentin

2004-12-07, 4:19 am

<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/

Joe English

2004-12-07, 4:19 am

Csaba Nemethi wrote:
>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 ""?

The next release will have more introspection features,
so you'll be able to query the style to get option defaults.

But note that many options won't be available from the theme,
either -- for example, on OSX, Windows XP, and with most pixmap
themes, there won't be a button -background option at all.

In the case of fonts, Tile provides and uses a standard set of
named fonts based on TIP #145; you can use a hardcoded value
of e.g., "TkDefaultFont" instead.

>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.

[style theme use] is one of the introspection features
to be available in the next release. (I would add, however,
that any application that really cares what the current theme is
is probably doing more work than it ought to.)

>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).

This is actually retro-compatible with Tk 8.3, which had a
single "-pad" option. Tk 8.4 broke backwards compatibility
when it split that up into separate "-padx" and "-pady" options;
I figured if that incompatibility was justifiable, then Tile
could do it again :-)

> 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 you build the Tile package with -DNO_COMPAT -- which
I recommend doing, since that will be the default at some
point in the future -- these will go away entirely.

>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.

This was a tough call, but in this case backwards-compatibility
(of a sort) won out. The main rationale for keeping -state
while dropping so many other options is that '-state' affects
functionality, not just appearance. I'd like to make this
read-write instead of write-only, but getting this right,
and backwards compatible, is hard.

>I hope, my remarks above won't hurt anybody. They are meant as
>positive criticism,

Taken as such :-)

--Joe English

vince.darley@eurobios.com

2004-12-07, 9:05 am

Bob Techentin wrote:
> <vince.darley@eurobios.com> wrote
> ...
>
>
> 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.

I think we're arguing at cross-purposes here. I agree with everything
you say, except for the 'the only reason' bit.

90% of time (perhaps 99%) of the time, I just want to use the widgets
as is. But in any reasonably complex application there will be special
cases where to achieve the application's requirements (whether a legacy
app or a new one -- I hope Tile is targeting _both_!), I need to
override the options on a few widgets. Tile forces me to create new
styles for that. One example I have is the need to programmatically
create a layout of a dozen or so checkbuttons, sometimes with fairly
long labels which I want to wrap. But Tile won't let me set the
-wraplength on a checkbutton, nor the -anchor, so I have to hack around
with all sorts of other mess. Some of that mess makes me create new
styles, and the code is just horrible.

Another use is for coloured buttons to control specific things. There
are _some_ interfaces (not many, I'll admit) where it is useful to have
coloured buttons (which coordinate with the colours of something else
related). Tile doesn't let me do that easily, if at all.

So, Tile is great 90% of the time, but the rest? (And please don't say
I should just mix Tile and Tk widgets....)

> 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).

This argument is just a red-herring. I'm not talking about controlling
every widget, just a small number for special purposes.

> (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.)

I'm not talking about themes, I'm talking about layouts -- try
executing this code twice in a row:

style theme settings xpnative {
style layout TCheckbutton {
Checkbutton.indicator -side left -sticky nws
Checkbutton.label -side left -sticky nwse
}
style default TCheckbutton \
-justify left -anchor nw
}

and you will get an error. You can't change or redefine an existing
'style layout' on the fly. Tcl and Tk are very dynamic languages, yet
Tile insists on being static in this respect!

I really think Tile is great, but it's a shame it has decided to take
it's own path at a tangent to what Tcl,Tk have always tried to do.
cheers,

Vince.

Jeff Hobbs

2004-12-07, 4:04 pm

vince.darley@eurobios.com wrote:
> 90% of time (perhaps 99%) of the time, I just want to use the widgets
> as is. But in any reasonably complex application there will be special
> cases where to achieve the application's requirements (whether a legacy
> app or a new one -- I hope Tile is targeting _both_!), I need to
> override the options on a few widgets. Tile forces me to create new
> styles for that. One example I have is the need to programmatically

Please join and read tktable-tile-dev before going into long
debates about tile, because a lot of this has already been
answered there. The short of it is that Tk 8.5 will have *2*
sets of widgets: the standard (classic) ones in tk::*, and
the new ones in ttk::* (for themed Tk). The default (the
toplevel ::* widget names) for 8.x will point to tk::*, but
easily switched to ttk::*.

We expect that >95% of the time, people would be happy with
using pure themed widgets. Obviously there are special cases,
and many of those special cases can be handled by using one of
the classic widgets directly.

> override the options on a few widgets. Tile forces me to create new
> styles for that. One example I have is the need to programmatically
> create a layout of a dozen or so checkbuttons, sometimes with fairly

This has already been stated as an area needing work.

> Another use is for coloured buttons to control specific things. There
> are _some_ interfaces (not many, I'll admit) where it is useful to have
> coloured buttons (which coordinate with the colours of something else
> related). Tile doesn't let me do that easily, if at all.

This relates to the above - you would likely have to not use
tile buttons in this case. Show me a standard app on Windows
that has a colored button.

> So, Tile is great 90% of the time, but the rest? (And please don't say
> I should just mix Tile and Tk widgets....)

Yes, you should, what's your problem with that? I encourage
people to actually try developing with tile. If you find
yourself struggling with options and such, I would argue you
are not creating a standard interface. OK, some don't want
that (specialized fields like CAD can of course have very
specialized UIs), but then you have all of classic Tk there
for you as well.

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

Bob Techentin

2004-12-07, 4:04 pm

<vince.darley@eurobios.com> wrote
> One example I have is the need to programmatically create a layout
> of a dozen or so checkbuttons, sometimes with fairly long labels
> which I want to wrap. But Tile won't let me set the -wraplength on
> a checkbutton, nor the -anchor, so I have to hack around with all
> sorts of other mess. Some of that mess makes me create new styles,
> and the code is just horrible.
>
> Another use is for coloured buttons to control specific things.
> There are _some_ interfaces (not many, I'll admit) where it is
> useful to have coloured buttons (which coordinate with the colours
> of something else related). Tile doesn't let me do that easily, if
> at all.
>

Maybe there are ways to use standard themed widget styles, but still
get the same usability. How about just skipping the checkbutton label
text and gridding together a checkbutton and a label? Tile's label
supports -wraplength. And will your users easily recognize a compound
button with a colored image? That would eliminate the eye strain of
trying to read black text on a blue background.

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/

vince.darley@eurobios.com

2004-12-07, 4:04 pm

Jeff Hobbs wrote:
> vince.darley@eurobios.com wrote:
widgets[color=darkred]
special[color=darkred]
legacy[color=darkred]
new[color=darkred]
programmatically[color=darkred]
>
> Please join and read tktable-tile-dev before going into long
> debates about tile, because a lot of this has already been
> answered there.

I have looked -- there's only one relevant thread, as far as I can see
(please do point me to anything more), which doesn't draw any
conclusions about what should definitely be done, and many of my
various bug reports have led to the conclusion of either "don't do
that" (not much help with a legacy application), or "use this
workaround with mixtures of labels and checkbuttons and snit and ..."
(which kind of work, but just show me how complicated Tile is going to
be to use in the 5%-10% of cases that are not straightforward) -- which
is somewhat discouraging.

say[color=darkred]
>
> Yes, you should, what's your problem with that?

The problem is that you can't nicely mix Tk & Tile widgets in the same
dialog or frame. They tend to look ugly together. While for the case
of button backgrounds one could imagine these special buttons being all
Tk and other 'normal' buttons being Tile. In most cases mixing things
is just awful. Say, I need to over-ride just the -anchor or -wraplength
or -justify on something, I can hardly mix Tk and Tile checkbuttons
side by side.

Anyway, these are just my experiences from trying to use Tile. I want
to use it (and in _new_ applications I'm sure it's much easier), but
converting old applications is rather complicated.

I hope these comments give some impetus to making Tile even better!
cheers,

Vince.

vince.darley@eurobios.com

2004-12-07, 4:04 pm

vince.darley@eurobios.com

2004-12-07, 4:04 pm

Joe English

2004-12-08, 3:58 am

Vince Darley wrote:
>
>90% of time (perhaps 99%) of the time, I just want to use the widgets
>as is. But in any reasonably complex application there will be special
>cases where to achieve the application's requirements (whether a legacy
>app or a new one -- I hope Tile is targeting _both_!), I need to
>override the options on a few widgets. Tile forces me to create new
>styles for that. One example I have is the need to programmatically
>create a layout of a dozen or so checkbuttons, sometimes with fairly
>long labels which I want to wrap. But Tile won't let me set the
>-wraplength on a checkbutton, nor the -anchor, so I have to hack around
>with all sorts of other mess. Some of that mess makes me create new
>styles, and the code is just horrible.
>
>Another use is for coloured buttons to control specific things. There
>are _some_ interfaces (not many, I'll admit) where it is useful to have
>coloured buttons (which coordinate with the colours of something else
>related). Tile doesn't let me do that easily, if at all.

I know this sounds paradoxical, but that's *exactly why*
(for example) Tile buttons don't have a working -background option.

[ttk::button] is supposed to give you a standard button on
whatever platform you happen to be on. Standard buttons on
OSX and Windows XP don't let you change the background color,
at all. So if you're using (say) "-background green" to convey
real information (and not just because you happen to like the
color green), then you need to create a custom widget.

Now Tile buttons could have included a "-background" option
that only works if the underlying platform or theme happens
to support it. I really don't think that's a good idea though,
and don't intend to support it. I *do* want to make it easy
to create custom widgets, and I think Tile does a pretty good
job there, especially when combined with SNIT.

--Joe English

Donal K. Fellows

2004-12-08, 3:59 pm

vince.darley@eurobios.com wrote:
> The problem is that you can't nicely mix Tk & Tile widgets in the same
> dialog or frame. They tend to look ugly together. While for the case
> of button backgrounds one could imagine these special buttons being all
> Tk and other 'normal' buttons being Tile. In most cases mixing things
> is just awful. Say, I need to over-ride just the -anchor or -wraplength
> or -justify on something, I can hardly mix Tk and Tile checkbuttons
> side by side.

FWIW, I'd say those three options (particularly -wraplength, which is
rather specialized in the first place) are perhaps better not being
styled at all.

> Anyway, these are just my experiences from trying to use Tile. I want
> to use it (and in _new_ applications I'm sure it's much easier), but
> converting old applications is rather complicated.

In my (limited) experience, the more highly tuned the GUI the harder it
is to convert. Getting something working exactly as before with the tile
widgets can be very difficult; I suspect this is actually because the
right approach will be to use a different strategy (e.g. different
widgets laid out differently). A good conversion is non-trivial. :^/

Donal.

Jeff Hobbs

2004-12-20, 8:58 pm

Bryan Oakley

2004-12-20, 8:58 pm

vince.darley@eurobios.com wrote:

> I'm glad at least some of the TCT are acknowledging these difficulties.
> Most messages from normally-helpful-people seem just to say that what
> I'm trying to do "isn't sensible", "is wrong", "is not the right way to
> do things", etc.
>

I think the point is, the expected use of tile is to accept all the
defaults and not tweak them to your liking. The whole point of tile (at
least from my perspective) is that you don't have to do anything to get
proper platform look and feel, and that there won't be many tk-like
options to allow you to deviate from that. If you need a unique look, do
the work by creating your own styles rather than by tweaking options.

It's not that the tweaking can't be done, just that you have to do it in
a different way.

> The point is, I'm trying to convert an application which works
> *perfectly well* with Tk 8.4/8.5 on *multiple* platforms and start
> using Tile. And what I've learned? Tile is a big pain.

If it works perfectly well, why switch to a different toolkit with
different design goals? I don't understand your motiviation.

I'm not surprised it's a pain -- tk and tile have two slightly different
design goals. I personally don't plan on migrating myself so much as
rewriting all the GUI portion of my code. For my apps, that's a
relatively small percentage of code. That is, probably 80-90% of my code
does real work and only 10% to 20% has to do with widgets and layouts,
if that. My experience may not match your particular code base of course.

> ...
> That would be a great thing to do, if someone could tell me where I'm
> going to find the time to do all that! Given time is limited, I'm
> trying to *migrate* to Tile slowly, and that is apparently not possible
> or sensible!

I don't yet have enough experience under my belt with tile to say
whether it's truly sensible or not, but it doesn't sound particularly
sensible to me. If you have an app that works, and you don't seem to
want all of the features that tile promises, why switch?

Donald Arseneau

2004-12-21, 3:57 am

Jeff Hobbs <jeffh@removethis.activestate.com> writes:

> vince.darley@eurobios.com wrote:
>
> Hmmm, what you should have learned is that tile still returns
> a version number < 1.0 when you package require it. That
> should tell you something about the state of the package.

It tells me that *now* is the time to complain... err ...
provide feedback ... before it gets finalized.

Given that I do want to alter some widgets in my apps, it looks
like tile is out of the picture. But it doesn't do to ignore tile
development because tile seems to be closer to core-support than
other widget extensions, and tile does provide new widgets. I worry
about a permanent gulf between tile giving no control over appearance
and Tk insensitive to system preferences.

Donald Arseneau asnd@triumf.ca

Jeff Hobbs

2004-12-21, 3:57 am

vince.darley@eurobios.com wrote:

> Bob Techentin wrote:
>
>
> That does work reasonably well, and maybe I'll end up doing that.
>
> But I have to ask "Why?". If I can put a checkbutton and a label
> together to mimic this (with a lot of hassle!), then why doesn't the
> checkbutton simply support it?
>
> The checkbutton supports multi-line text (try inserting \n manually),
> but it doesn't support -wraplength or -justify? That's just not
> sensible!

Does it on all platforms though? If I remember one aspect of
OS X buttons that is enforced by the Aqua toolkit, it is that
they do *not* support multiline buttons. So the regular Tk
button has -wraplength and -justify, but that's just ignored
by Tk. That may apply to the checkbutton as well (can someone
with OS X verify?). If that's the case, then the tile lack of
those options is sensible.

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

vince.darley@eurobios.com

2004-12-21, 8:57 am

Jeff Hobbs wrote:
> vince.darley@eurobios.com wrote:
manually),[color=darkred]
>
> Does it on all platforms though? If I remember one aspect of
> OS X buttons that is enforced by the Aqua toolkit, it is that
> they do *not* support multiline buttons. So the regular Tk
> button has -wraplength and -justify, but that's just ignored
> by Tk. That may apply to the checkbutton as well (can someone
> with OS X verify?).

Checkbuttons on Aqua do support multi-line text, -wraplength, -justify,
etc.

> If that's the case, then the tile lack of
> those options is sensible.

Well, that's not the case. Does that allow us to conclude that tile's
lack of these options is *not* sensible.... ;-)

As a side note, 'Buttons' on Aqua do not support multi-line text, as
you say, but Tk seems to have concluded that the sensible approach was
simply to document on which platforms multi-line text would not be
supported, and provide as much support as possible. Tile's approach is
to say that such multi-line text/justify/wraplength stuff should be
disallowed on all platforms.

That's a major difference:

Tk: maximal flexibility within platform constraints
Tile: lowest common denominator

Which is more sensible? Tile is probably always going to be *more*
constrained than Tk, and that's ok, but Tile is currently also more
constrained than is *necessary* (IMHO), and I believe it would benefit
by being a bit more flexible and Tk-like.

cheers,

Vince.

Jeff Hobbs

2004-12-21, 4:00 pm

vince.darley@eurobios.com wrote:
> As a side note, 'Buttons' on Aqua do not support multi-line text, as
> you say, but Tk seems to have concluded that the sensible approach was
> simply to document on which platforms multi-line text would not be
> supported, and provide as much support as possible. Tile's approach is
> to say that such multi-line text/justify/wraplength stuff should be
> disallowed on all platforms.
>
> That's a major difference:
>
> Tk: maximal flexibility within platform constraints
> Tile: lowest common denominator

Most people seem to have this discussion without any regard for
the history of Tk. Remember that it all started on X, only
supporting X. A lot of Tk code still only makes sense on X.
Tile in part is trying not to make similar compatibility
mistakes. The checkbutton may well need these options, but the
above is not a correct assumption IMO.

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

Joe English

2004-12-21, 8:57 pm

Donald Arseneau wrote:

>It tells me that *now* is the time to complain... err ...
>provide feedback ... before it gets finalized.
>
>Given that I do want to alter some widgets in my apps, it looks
>like tile is out of the picture. But it doesn't do to ignore tile
>development because tile seems to be closer to core-support than
>other widget extensions, and tile does provide new widgets. I worry
>about a permanent gulf between tile giving no control over appearance
>and Tk insensitive to system preferences.

Please take a look at the screenshots here:

http://tktable.sourceforge.net/tile/

Of particular interest:

http://tktable.sourceforge.net/tile...o-clam-unix.png
http://tktable.sourceforge.net/tile...nix-keramik.png
http://tktable.sourceforge.net/tile...emo-xp-blue.png

Considering what's _already_ possible (and keeping in mind
that it's not even finished yet), I don't see how one can
come to the conclusion that Tile gives no control over appearance.

--Joe English

Sponsored Links