Switching from Tk to Ttk
Francois Vogel
I'm maintaining an application that must run on Tcl/Tk 8.4 and 8.5 as
well.
Since 8.5 now includes Tile (Ttk), I had a try in using Ttk. In
practice, depending on the (8.4 or 8.5) environment I use Tk widgets
or Ttk widgets. In Tk8.4, Tk widgets are used. In Tk8.5, Ttk widgets
are used.
Overall, practice shows that this sort of things is not so easy (see
below).
Therefore my first question: Is there any guidelines somewhere
targeted to easing switching from Tk widgets to Ttk widgets? I
couldn't find any on the wiki.
In my app, as a practical exercise I started by converting the
panedwindow. First thing, I created my vanilla Tk panewindow by:
panedwindow .pw -orient vertical
This translates to:
ttk::panedwindow .pw -orient vertical
Straightforward (well, I leave out here tests on $Tk85).
Problems come when non existing (in Ttk) panedwindow or pane options
are called, such as -minsize. OK, let's catch this (to avoid a test on
$Tk8.5), but at the same time I have to write a proc bounded to
<Configure> that will handle the missing feature. Kind of a pain.
Also, why does a Ttk panedwindow have different command names compared
to the Tk panedwindow (example: sash coord / sashpos)? This does not
ease using Ttk at all, and needs tests on $Tk85 to know what command
must be called. Or is there any better way? A wrapper?
Also, a Ttk panedwindow apparently cannot change its orientation once
created. Attempts to do it result in an error: "Attempt to change
read-only option".
Why does the Ttk panedwindow have a readonly -orient, while the Tk
panedwindow can change orientation? This is a showstopper for my
Tk-->Ttk switching process and is not documented in the
ttk:panedwindow man page.
Overall, modifying an application so that it uses Ttk widgets instead
of Tk widgets looks quite difficult to me. I would happily read any
advice on this, best by people who actually performed such a switching
in their apps, or even better by people who need to maintain an
application running on both Tk8.4 and 8.5.
Many thanks for reading that far.
Francois
Gerald W. Lester
> Hi all,
>
> I'm maintaining an application that must run on Tcl/Tk 8.4 and 8.5 as well.
>
> Since 8.5 now includes Tile (Ttk), I had a try in using Ttk. In
> practice, depending on the (8.4 or 8.5) environment I use Tk widgets or
> Ttk widgets. In Tk8.4, Tk widgets are used. In Tk8.5, Ttk widgets are used.
>
> Overall, practice shows that this sort of things is not so easy (see
> below).
To make it easier, in your 8.4 environment do:
package require tile
Then just use ttk widgets in both
> ...
> Overall, modifying an application so that it uses Ttk widgets instead of
> Tk widgets looks quite difficult to me. I would happily read any advice
> on this, best by people who actually performed such a switching in their
> apps, or even better by people who need to maintain an application
> running on both Tk8.4 and 8.5.
See above.
--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Francois Vogel
> package require tile
>
> Then just use ttk widgets in both
Thanks for your help.
Unfortunately, this is not an option for me. I'm shipping my app as
part of a larger structure which has a somewhat fixed environment.
Tile is not part of the 8.4 version that comes with this environment.
Francois
Larry W. Virden
Since Tile is a downloadable piece of free software, you should be
able to download it, build it, and include it as part of the code that
you ship, right?
Mark Roseman
essentially be building up a general purpose compatibility layer, and
spend a good chunk of time maintaining that. Some people have tried
this before ('chameleon' in aMSN for example), but it's hard to keep up.
Keeping the app using the classic widgets, and then incrementally
translating bits to Ttk would be the easiest transition strategy for
someone migrating their app altogether from classic Tk to themed Tk. In
your case, doing so as well would probably be wise, though it's of
course more work because of the additional conditionals and increased
testing load.
Any reason not to keep it in classic Tk until you know you have a themed
Tk environment available? (Keeping in mind that if someone bitches,
it's an argument for pushing faster to migrate to 8.5).
Mark
Francois Vogel
> > Unfortunately, this is not an option for me. I'm shipping my app as
> > part of a larger structure which has a somewhat fixed environment.
> > Tile is not part of the 8.4 version that comes with this environment.
>
> Since Tile is a downloadable piece of free software, you should be
> able to download it, build it, and include it as part of the code that
> you ship, right?
Well, in principle yes.
Currently I have no C code coming with my Tcl/Tk app. Only the
surrounding environment has C code. This environment integrates my app
and is shipped and maintained by somebody else.
I would like to avoid adding the burden of compiling tile when
compiling the whole environment.
I could think of embedding a binary version of tile (is this
possible?) in the part that *I* provide, but it would be a bit shaky
especially considering cross-platform issues.
Francois
Gerald W. Lester
Yes it is entirely possible.
You would include the tile shared library in the correct format for the
systems you support. Then you create/edit the pkg_index.tcl file for tile
and use the [info sharedlibextension] along with the entries in the
::tcl_platform array to pick which one to load (use the load command to load
the correct file).
Note -- you may only need to use [info sharedlibextension].
Francois Vogel
> This will be very hard to do in a painless way. As you go along, you'll
> essentially be building up a general purpose compatibility layer
Ageed. This is also my (sad) conclusion after having actually tried.
> Keeping the app using the classic widgets, and then incrementally
> translating bits to Ttk would be the easiest transition strategy for
> someone migrating their app altogether from classic Tk to themed Tk. In
> your case, doing so as well would probably be wise, though it's of
> course more work because of the additional conditionals and increased
> testing load.
I will perhaps go for that "solution". Or just keep old Tk widgets
since it's really too difficult to switch.
But let's suppose I migrate my application widget by widget, one after
the other. What would be the look and feel of a toplevel having some
Ttk widgets mixed with some Tk widgets? Wouldn't I loose everything
(i.e. consistency while still not having complete look and feel
brought by Ttk) ?
> Any reason not to keep it in classic Tk until you know you have a themed
> Tk environment available? (Keeping in mind that if someone bitches,
> it's an argument for pushing faster to migrate to 8.5).
Yes, as a last resort argument perhaps. The user base is quite large,
and it's probably not possible to make any assumption about 8.5
availability in their machines, at least so shortly after the 8.5
release.
In fact I'm mixed. Tile seems to provide modern look and feel while
being a pain to use when replacing old Tk widgets. Tile also has new
interesting widgets such as the combobox, notebook or progressbar,
which I would happily use and which Tk<8.5 lacks. I know, there are
extensions for that. Well, really mixed.
Difficulties in migrating really are large. I have read this page for
instance:
and it's not encouraging at all, to say the least. For instance I can
read statements like:
"Tile just isn't suited to updating complex applications. It demands
such a different approach that it's only good if that approach is
incorporated into the design from the beginning"
"I was excited about Tile for a while. I converted several
applications to use it. Then I upgraded to tile07.kit and found that
most of my applications broke. They were unusable.... So, I have
removed Tile from all but 1 application"
"Certainly, changing an entire app to use Tile is (IMHO) difficult,
unnecessary and undesirable"
Oh well...
Perhaps hope can come from the bottom of the wiki page I mentioned
above, where there is a discussion about a Tk-Ttk wrapper code named
chameleon written for helping transition of aMSN from Tk widgets to
tile. You have mentioned this in your post and I have to say that this
looks VERY interesting if it can work.
The question is will chemeleon become available and included in Tk or
maybe better of Ttk included in 8.5? What is the status on this,
including license issues? The chameleon author seems to say that Ttk
authors are (were?) interested in integrating chameleon in Ttk.
Francois
Arndt Roger Schneider
Well, your post is a sad one.
Tile and Tk do not work well together,
the concept for both is way to different.
Tk 8.0 statement was: Platform conformance
and tile is the anatheme to that.
Well (again) if tile would have be able
to fork Tk, so be it;
but it didn't and worse was incorporated
into Tk, which makes anyone wonder what is
Tk anymore --me too.
For me: I don't need tile (I am not working
on themed OSs anyway and hence do not have any
need for "themes"-
Incorporating themes into your current application
is a logical effort, one which you have to address
inside of a higher level (that is how I did addressed
it, but I did have the infrastructure in place
anyway)...
-roger
Mark Roseman
> Tile and Tk do not work well together,
> the concept for both is way to different.
> Tk 8.0 statement was: Platform conformance
> and tile is the anatheme to that.
>
> into Tk, which makes anyone wonder what is
> Tk anymore --me too.
>
> For me: I don't need tile (I am not working
> on themed OSs anyway and hence do not have any
> need for "themes"-
Hi Roger,
I believe that for most people and most applications, the "theme" aspect
of themed Tk is quite secondary; the use of the appropriate default
themes on Mac, Windows and Linux is entirely sufficient. In the sense
that themed Tk abstracts and isolates the platform differences in a
theme, it can be said to help rather than hinder platform conformance.
The analogy with complex options on HTML tags vs. CSS is useful I think.
The themed Tk widgets should be your "everyday" widgets, with special
styles and themes used to handle particular classes of behavior for your
application. The Tk widgets are available as fallback for when you need
some really funky configuration behaviors.
The above is in an ideal world, and themed Tk is not there yet. Styles
and themes are hard to understand and manipulate. There are things that
can/should be done to rationalize them a bit better, and I'd just as
soon have a new "gui" (or whatever) package that used Tk or themed Tk
underneath so that I didn't have to remember what widgets existed or
didn't exist in which place.
I hope we continue to evolve towards a more rational and unified GUI
toolkit. It would have made figuring it all out for
http://www.tkdocs.com much simpler! :-)
Mark
MSE...@gmail.com
wrote:
I do not entirely agree with your conclusion.
Your problem is that you do not know what is available beforehand and
have to code for two different systems if you want to use one or the
other.
I deliver applications as starpacks which include both TK and tile and
freely use both together (Bwidget tree/notebook) with no problems.
They do work well together. they are just different. Tile/ttk is just
another library of available widgets, not a drop in replacement.
Relying only on what TCL/TK system is installed on any particular
machine is always a very risky affair.
I have had lots of problems including missing subcommands, colour
names and such from very minor version changes in TCL.
Cameron Laird
Mark Roseman <ma...@markroseman.com> wrote:
> Arndt Roger Schneider <roger.s...@addcom.de> wrote:
>> Tile and Tk do not work well together,
>> the concept for both is way to different.
>> Tk 8.0 statement was: Platform conformance
>> and tile is the anatheme to that.
>>
>> but it didn't and worse was incorporated
>> into Tk, which makes anyone wonder what is
>> Tk anymore --me too.
>>
>> For me: I don't need tile (I am not working
>> on themed OSs anyway and hence do not have any
>> need for "themes"-
>
>
>Hi Roger,
>
>I believe that for most people and most applications, the "theme" aspect
>of themed Tk is quite secondary; the use of the appropriate default
>themes on Mac, Windows and Linux is entirely sufficient. In the sense
>that themed Tk abstracts and isolates the platform differences in a
>theme, it can be said to help rather than hinder platform conformance.
>The analogy with complex options on HTML tags vs. CSS is useful I think.
>
>The themed Tk widgets should be your "everyday" widgets, with special
>styles and themes used to handle particular classes of behavior for your
>application. The Tk widgets are available as fallback for when you need
>some really funky configuration behaviors.
.
.
I have successful desktop applications that mix Tk and Ttk.
I'm not sophisticated about visual styling, though; mostly
I just need notebooks, comboboxes, and so on.
tonytraductor
While I am not the most skilled or experienced tcl-er on this list, I
have to say that I have used
Tcl8.5 for my most recent creations, but have used combinations of tk
and ttk widgets without issue.
I have used largely tk elements, since ttk elements don't seem to like
color themeing, more than anything, but
where a widget doesn't exist in tk, I use the ttk elements.
I have only called wish8.5 of tclsh8.5 to run these apps, which
doesn't seem to pose any problem in using
earlier tk elements at all. This gives me all the functionality of
tlc8.5, while maintaining the look and functionality of
earlier tk widgets.
As an example, the menu bar in Tickle Text (http://www.linguasos.org/
tcltext.html) has tk menu buttons, tk buttons, but a ttk::combobox.
They seem to work fine side by side.
Or, if the issue is that you have a tcl8.4 app and want to run it with
tcl8.5, I can't imagine tcl8.5 having any difficulty whatever
running code written for 8.4.
As such, I don't exactly understand where you are having difficulty.
That may be due to ignorance...I don't know.
Arndt Roger Schneider
I agree with your rationale.
Things were pretty easy when Tk 8.0 was
released : Almost everyone agreed on how
an application should look and behave on a
certain platform.
These days are gone!
The separation between representation and
logic was already realized in Tk:
Any cusomization could have and should have been
put into the option database.
The option database provides a deep structure
access to the presentation of an application, while
themes are only concerned with the visual
aspect (that is a very flat structure).
The issue deep versus presentation structure
was fought out in the documentation area, too.
And the result is: that deep structure (based on XML)
did win --for technical reasons and above all
flexibility.
Realising themes inside of the framework of vanilla Tk
is indeed not that much work, rather the opposite.
What you need to fulfill platform compliance is
dominantly color related.
So the proper solution is a CMS (Color Management System),
using synthetic color names such as KDESystemButton.
These are things we all know very well from
windows, MacOs and OSX.
Now, add shape-fonts, where the graphical
fragments, of the toolkit, are glyphs inside of
two fonts (one vertical and another one horizonal).
Flexibility!!!
An adaptable toolkit (flexible) is what you and
I need, because neither you nor I can predict what
will happen in the future.
-roger