ANNOUNCE: TileQt, version 0.3
The third release of TileQt! Now with a different style per interperter!
Also, I want to thank Csaba Nemethi for evaluating TileQt 0.3
pre-releases and providing valuable bug reports and suggestions!
~ What is it?
TileQt is a tile theme, which draws tile widgets with the
current (or any other) KDE widget style, thus making tile widgets
look native under the KDE desktop.
~ What's New in 0.3
1) Different Qt styles can be used in different interpreters (thus
allowing the tileqt style selection dialog to run in the same process
:-) ) (Many thanks to Jeff Hobbs for pointing that tile can support
different themes under different interpreters).
2) Improved visual display of notebook widgets. For the first time tab
base bar is drawn by tileqt (i.e. the Metal4Kde & Liquid themes).
Also, notebook tabs are resized correctly, to cope for "strange" tab
shapes, like the triangular ones used in Metal4Kde (which you can
find in kde-look.org).
3) Better handling of widget colours according to widget states.
4) A new demo has been added (WidgetStates.tcl) which will show various
widgets in various states.
5) Finally, TileQt is able (again) to receive notifications from KDE
control center, when the user changes the style used by the desktop.
However, due to an unknown problem regarding XEvent handlers, only
widgets in the last created interpreter that has loaded the TileQt
extension will be notified. Notification will be made through the
<<ThemeChanged>> virtual event, whice will be generated by TileQt
on any style change.
~ Availability:
Home page:
http://www.ellogon.org/petasis/index.php?option=com_content&task=view&id=24&Itemid=40
SF Home Page:
http://sourceforge.net/projects/tktable/
Downloads are available at:
http://www.ellogon.org/petasis/index.php?option=com_content&task=view&id=24&Itemid=40
Screenshots are available at:
http://www.ellogon.org/petasis/index.php?option=com_content&task=view&id=24&Itemid=40
Feedback and bug reports are greatly appreciated.
-
George Petasis
The screenshots look good. I haven't looked at Tile yet but I was
wondering what it would take to start using it. Would I need to rename
all widget creation commands to the ttk:: versions? Is there a way
this oculd be done transparently? So it becomes easy to swicth back
and forth.
You might start by reading this:
From my perspective, switching back and forth doesn't make sense. The
philosophy of tile is different than that of Tk. IMO, Tk provides
building blocks which can be customized to achieve a certain look. Tile
OTOH provides a specific look that should not be customized. I'm not
sure if others share that view; that's just how I see it.
You can mix the two though, so my recommendation is to use Tile for 95+%
of the GUI, and use tweaked core tk widgets for the things that need
heavy customization. For legacy applications that means a small rewrite,
but the transition should be mostly mechanical (e.g. replace "button .b
<options>" with "ttk::button .b <fewer options>")
--
Bryan Oakley
http://www.tclscripting.com
You can always do a namespace import on ttk, then use tcl:: to access the
"classic" widgets.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
That's not recommended anymore. Joe English removed that support
essentially. Many things in Tk dialogs and other widgets will break in
0.7 with that approach.
-George
Gerald W. Lester wrote:
> Bryan Oakley wrote:
>> ...
>>
>> You can mix the two though, so my recommendation is to use Tile for
>> 95+% of the GUI, and use tweaked core tk widgets for the things that
>> need heavy customization. For legacy applications that means a small
>> rewrite, but the transition should be mostly mechanical (e.g. replace
>> "button .b <options>" with "ttk::button .b <fewer options>")
>
> You can always do a namespace import on ttk, then use tcl:: to access
> the "classic" widgets.
>
bad idea. ttk widgets are not direct drop in replacements for tk widgets
the available options are different and ttk no longer silently ignores
unsupported options - it will error.
Bruce
More accurately: I didn't remove support for it -- it never worked
properly to begin with -- I just gave up on trying to make it work.
> Many things in Tk dialogs and other widgets will break in
>0.7 with that approach.
That's always been the case -- it never did work.
However, if you need to support both tile and core widgets, you can
conditionally import ttk::* widgets into your own namespace(s)
as long as you stick to the intersection of what's documented for
Tile 0.7 and Tk 8.4. Just don't import ttk::* into the global
namespace, since that's known to break stuff.
--Joe English
>However, if you need to support both tile and core widgets, you can
>conditionally import ttk::* widgets into your own namespace(s)
>as long as you stick to the intersection of what's documented for
>Tile 0.7 and Tk 8.4.
/me *smacks forehead*
Of course, there's also the Chameleon package:
<URL: http://amsn.sourceforge.net/kakaroto/Chameleon/ >
<URL: http://wiki.tcl.tk/15443 >, towards the bottom
Chameleon is a comprehensive wrapper around the ttk::* widgets
that provides a much higher level of 8.4 compatibility than
Tile ever did.
--JE