Tk in comparison to other portable toolkits
George Peter Staplin
my work to make it work properly with Whim (a Tcl/Tk WM) it is poorly
implemented in some ways. I now have Java apps working well though,
after some hackery.
The primary Enlightenment author also experienced similar problems and
documented them:
http://lists.freedesktop.org/archives/xorg/2005-October/010527.html
I also reported a bug to Sun a couple of months ago.
Gtk+ has a large developer community. I've worked with this more than I
would have liked. The API is extensive, and for the most part powerful.
It's awkward in C though to create widgets. There are also GUI builders
for it that work pretty well, though I had problems when I used them. I
think Tcl provides for a good abstraction for Tk in comparison.
WxPython threatens to take Tk/Tkinter out of Python's distribution.
WxWidgets for the most part seems well implemented. This may be
Tcl/Tk's main competitor for those of you in the commercial GUI
scripting world. They have native look and feel, plus portability from
what I've seen, and the applications I've used. I think we could
leverage some sort of Tk in the future like they do, by having someone
like Steve Landers or The Hypnotoad create videos demonstrating how
things work, and how to get to create some simple things. Perhaps
these videos could go on Youtube and similar sites, to reach a broader
audience.
Most of the world isn't aware of Tcl/Tk, and it's time we change that,
by branching out into wider audiences when possible and appropriate.
What are your thoughts on what Tk is missing in comparison to other
toolkits? What can we learn from others? What can we do to best
demonstrate the unique capabilities of Tcl when combined with a toolkit?
George
P.S. I'm also going to borrow the input here for my NexTk. :-)
Aric Bills
I was going to post my Tk feature request here, but I think it's more
appropriate to post it elsewhere. But since I failed to respond in
the NexTk image viewer thread, let me just say here that your work is
really interesting and I'm eager to see how it develops.
Best luck and best regards!
ZB
> Most of the world isn't aware of Tcl/Tk, and it's time we change that,
> by branching out into wider audiences when possible and appropriate.
About 6 years ago I tried to take a look onto Tcl/Tk at first time. So,
I ran demo, I could see everything in that lately (at last) dropped
Motif-look (all in the gray cast-iron colour and deeply carved), and although
I could see, that it does allow to construct interactive GUIs - that gray
"look & feel" suggested, that I cannot use it for building anything looking
attractive for the end-user (of course, "eye-candy" GUI is important for
end-user). Obviously, I wasn't aware about possibilities available via
"option database", simply because I didn't examine the things close enough,
looking at that demo - and at other Tcl/Tk programs, which were exactly as
gray and "Motif-like" in their look (f.e. Susefax and some front-ends to Unix
commands, like ftp and so on).
Then I saw some freeware, open-source tools, made in Tcl/Tk, made looking
a bit nicer, but still it was nothing great: an RSS-feeder, some kind of
"desk-commanders" (a "launchpad" made by placing a few buttons, allowing to
run some commands, and file selection window) - so, it seemed, that Tcl/Tk
was not much more than xdialog, which sometimes I was using for construction
the simple tools, to make daily tasks easier. And xdialog even had a bit
better look, than earlier default Tk "skin". Besides: Tcl/Tk was slow at
that time (it was probably 7.x line?).
And about 2 years ago, when I was testing many Jabber-clients, I've found
Mats Bengtsson's Coccinella client; I was amazed, that it has been created
using Tcl. Although not immediately - I decided to take a bit closer look at
Tcl/Tk, and it's really a pity, that the grainy and not especially
interesting demo discouraged me earlier.
The demo-problem is, one can say, solved: the new demo looks much better.
But the other thing is, that it can be worthy to mention, what have been
created using Tcl/Tk - and, believe me: the information, that Tcl is used
for turning some radiotelescopes), or that AOL server is written in Tcl,
isn't as interesting, as the one, that it can be used for building the
applications of commercial quality, for average end-user. How many of
potential Tcl/Tk-designers are working at astronomical observatories, anyway?
So, very important is information (then links, some screenshots...) of the
type: "look, you can make something like this much easier, than with C++
- and having about the same quality as the result". And it wasn't about
AOL-server (although, of course, is another "plus" - that it can be used for
smaller and bigger things).
Such kind of "advertising" is needed, IMHO.
--
ZB
Keith Nash
its animations and transparency. E17 is now sufficiently mature to be the
default desktop environment for Yellow Dog Linux 5.0 on the Sony
Playstation 3.
The easiest way to try E17 is to get the live CD, as the build procedure is
rather complicated. The most striking item on the CD is an OS-X-like
animated taskbar (though unfortunately it is not configured as the default,
you have to switch it on).
E17 and its libraries might be of interest to Tclers because
* they use the BSD License
* they provide state-of-the-art 2D graphics, including animation,
transparency, and theming
* they try to be lightweight, with useful components placed in libraries
that can be re-used by other projects
In particular, the Enlightenment libraries are quite mature, and are the
result of literally years of effort by capable coders. If we want a
BSD-licensed 2D graphics toolkit with animation and transparency, it would
take us a long time to produce anything as good as this.
The project is intended to be cross-platform, but I have not attempted to
use its Win32 or OS X variants.
More info: http://wiki.tcl.tk/17329
Keith.
George Peter Staplin
Thank you. I look forward to seeing your post about Tk feature
requests.
George
George Peter Staplin
> I'm intrigued by the capabilities of Enlightenment 17 (E17), particularly
> its animations and transparency. E17 is now sufficiently mature to be the
> default desktop environment for Yellow Dog Linux 5.0 on the Sony
> Playstation 3.
>
> The easiest way to try E17 is to get the live CD, as the build procedure is
> rather complicated. The most striking item on the CD is an OS-X-like
> animated taskbar (though unfortunately it is not configured as the default,
> you have to switch it on).
I managed to build it with a Tcl script. I kid you not. I created a
script called evolve.tcl and had it run through build permutations until
it found the right pattern to build the snapshots.
Some of it is interesting. I suspect I missed the full effect though.
> E17 and its libraries might be of interest to Tclers because
> * they use the BSD License
> * they provide state-of-the-art 2D graphics, including animation,
> transparency, and theming
> * they try to be lightweight, with useful components placed in libraries
> that can be re-used by other projects
>
> In particular, the Enlightenment libraries are quite mature, and are the
> result of literally years of effort by capable coders. If we want a
> BSD-licensed 2D graphics toolkit with animation and transparency, it would
> take us a long time to produce anything as good as this.
I agree it will take time, but E17 isn't finished yet from what I
gather. And it's over 50,000 lines of code and growing.
I will look more at the sources, but to be honest I've had bad
experiences with the Rasterman's past efforts with E. I tried using E
several years ago, and it was too unstable for everyday use. However, I
don't want to judge his project based on that for the rest of my life.
Hopefully he's learned some better ways, just as I have to build quality
software.
> The project is intended to be cross-platform, but I have not attempted to
> use its Win32 or OS X variants.
>
> More info: http://wiki.tcl.tk/17329
Thanks for sharing that.
I have videos of Whim2 powered by NexTk, and a custom backing server.
It has some capabilities that others don't have yet, and also a problem
or 2 that I'm still working on.
Here's an early video of Whim2 using NexTk (hosted on sriv's server):
http://server.linuxsys.net/images/Whim2_awesome.ogg
I have some other better and more exciting movies that I'll talk with
sriv about hosting.
That's all software alpha blending and rendering. It's based on copying
the backing server framebuffer that is mmaped with MAP_SHARED, so it's
basically shared memory. It's pretty fun, but there are some challenges
to work out. Especially with regard to how large apps think the desktop
is with the portable X server I wrote called backing_server.
George
George Peter Staplin
> George Peter Staplin schrieb:
>> What are your thoughts on what Tk is missing in comparison to other
>> toolkits? What can we learn from others? What can we do to best
>> demonstrate the unique capabilities of Tcl when combined with a toolkit?
>
>
Why wouldn't you be? You don't have to be an expert to have a good
idea.
> But one of the
> biggest advantages of Tk compared with other toolkits is ease-of-use.
> I'm working in science, and basically none of our programs (doing
> numerical computation or instrument control) does really need a GUI, so
> usually we write command line programs. But Tk enabled me to make some
> of my programs easier, e.g. clicking on an image to give a point as a
> start parameter for some computation.
>
> Here is a talk I used to demonstrate this use to my colleagues:
>
> http://www.staff.uni-bayreuth.de/~btp916/StringKurs/TclTk/gui.pdf
I'll check that out.
> It's in German, but you should be able to understand the comparison
> between WinAPI, MFC, QT and Tk: It shows a program, that only displays
> one single clickbutton. In Tk:
>
> #!/usr/bin/wish
> button .b -text "Beenden TK" -command exit
> pack .b -side bottom
>
> WinAPI has 92 lines to achieve this trivial task, MFC needs 46, QT 23
> and Tk finally 2. While it might not be always a factor of 10-50, Tcl/Tk
> significantly makes it easy compared to other toolkits.
That's a very good point. The more of a barrier you have to expression
of your thought through code, the more bugs, you also usually have.
It's also difficult to keep more than a few lines of code in mind
perfectly at once, so less code and more abstractions allow us to be
more productive with higher quality. Assuming the abstractions minimize
side-effects.
> NexTk looks very promising. What I'm missing most in regular Tk is
> rotated text and antialiasing. I'd also like to have something similiar
> to Tk in 3 dimensions. Tcl3D looks very much like the C API of OpenGL.
I totally agree. Another thing I think is promising is Arnulf
Wiedemann's ntkWidget. He's using his itcl-ng (IncrTcl the next
generation) which is based on Donal K. Fellows' TclOO to build a widget
set using my code. We share ideas, and push each other a bit further.
I'm not totally convinced about using itcl-ng yet, because I'm not
sure about performance implications yet, but if it turns out well I may
start contributing directly to his project.
My NexTk is currently built around my [structure] command extension.
structure provides a sort of prototype object system, with methods, and
properties, with traces, and callbacks. I couldn't have built NexTk as
easily without it, if at all. Arnulf has been using some of the ideas
to build his ntkWidget, and expanded on them too.
> The analog of the clickbutton program would be a cube, that one can
> rotate with the mouse and click to trigger some action. It would be very
> cool to write something like
>
> package require Tk3D
> 3dcanvas .c
> .c create box -coords {{0 0 0 } {1 1 1}} -color green -tag greenbox
> .c bind greenbox <1> {exit}
That sounds good to me. I think the 3D canvas by D. R. Hipp provides
something like that, using OpenGL, though it's most likely a little more
complex based on the examples I've seen.
George
George Peter Staplin
> Keith Nash wrote:
>> result of literally years of effort by capable coders. If we want a
>> BSD-licensed 2D graphics toolkit with animation and transparency, it would
>> take us a long time to produce anything as good as this.
>
> I agree it will take time, but E17 isn't finished yet from what I
> gather. And it's over 50,000 lines of code and growing.
>
> I will look more at the sources, but to be honest I've had bad
> experiences with the Rasterman's past efforts with E. I tried using E
> several years ago, and it was too unstable for everyday use. However, I
> don't want to judge his project based on that for the rest of my life.
> Hopefully he's learned some better ways, just as I have to build quality
> software.
Looking at the sources to the Imlib2 snapshot I see code like this:
" hlut = malloc(sizeof(int) * ww);
vlut = malloc(sizeof(int) * hh);
if (ww > hh)
len = ww * 16;
else
len = hh * 16;
map = __imlib_MapHsvaRange(rg, len);
if (!map)
return;
xx = (int)(32 * sin(((angle + 180) * 2 * 3.141592654) / 360));
yy = -(int)(32 * cos(((angle + 180) * 2 * 3.141592654) / 360));
divw = ((ww - 1) << 5);
divh = ((hh - 1) << 5);
if (divw < 1)
divw = 1;
if (divh < 1)
divh = 1;
if (xx < 0)
{
for (i = 0; i < ww; i++)
hlut[i] = (-xx * (ww - 1 - i) * len) / divw;"
This suffers from several problems.
1. Imlib2 doesn't check the result of malloc. It must be assuming that
all the world is a Linux box with /proc/sys/vm/overcommit_memory set to
the default, so that the OOM killer will kill the process. Also, if for
instance you exceed a ulimit for the process, then it will result in a
segfault when hlut is accessed, rather than a nice error message if say
this was used:
if (NULL == hlut) {
perror ("malloc hlut");
abort(); //or exit (EXIT_FAILURE);
}
Unfortunately this malloc without error checking mistake is rampant
throughout the sources.
2. It leaks memory when !map is true. Notice how hlut is allocated, and
vlut are allocated, and then if !map it returns. A path later on
free()s hlut, and vlut, but it is never reached in the !map case.
3. Some of the procedures are too long, so obviously the programmer
didn't notice the patterns that I did. They are also deeply indented,
which isn't always bad, but when it's so general throughout the sources
I find it annoying, and confusing -- it's bound to result in spaghetti.
Linus Torvalds by the way recommends going no deeper than 3 indents in a
single function, and I think that's a good rule to live by for many (not
all) functions/procedures.
4. (not shown) some of the structs/functions are violating the rules of
C, by using an invalid _ prefix. __ prefixed symbols and macros are
reserved for the implementation. In fact using _ in general as a prefix
is a bad idea, unless you're implementing a C library.
It's disturbing when some of the first code I see is like this. My
conclusion is that it may work, but they will spend years tracking down
bugs, because they haven't taken the time to think things through
properly, or taken the critical review of better programmers seriously.
Note: I'm not saying I'm a better programmer, but many of these things
have been pointed out to me before, in my own poor code from years past.
Another thing I just found in rend.c:
__imlib_RenderImage(Display * d, ImlibImage * im,
Drawable w, Drawable m,
Visual * v, Colormap cm, int depth,
int sx, int sy, int sw, int sh,
int dx, int dy, int dw, int dh,
char antialias, char hiq, char blend, char dither_mask,
int mat, ImlibColorModifier * cmod, ImlibOp op)
It's as though some Imlib2 programmer has never heard of a struct, or
has an aversion to them (when I see that __imlib_RenderImage pattern).
A rule I'm reminded of by that function is Rule 5 from Rob Pike's list:
"Rule 5. Data dominates. If you've chosen the right data structures
and organized things well, the algorithms will almost always be
selfevident. Data structures, not algorithms, are central to
programming. (See Brooks p. 102.)"
http://www.lysator.liu.se/c/pikestyle.html
Anyway, I don't mean to be overly critical of E, but it seems clear that
the lazy coding style hasn't changed for the better to me. If it works
for you then that's good. I honestly hope you don't experience any
strange bugs.
My own lazy coding style is still evolving... I tend to prefer being
lazy when it comes to having to fix bugs, rather than when writing the
actual code and doing the design.
I also have a lot to learn still. My Win32 code still isn't great...
:-)
George
Alexandre Ferrieux
<georgepsSPAMME...@xmission.com> wrote:
>
> WxPython threatens to take Tk/Tkinter out of Python's distribution.
> WxWidgets for the most part seems well implemented. This may be
> Tcl/Tk's main competitor for those of you in the commercial GUI
> scripting world.
One thing about Tkinter is that it needs a full Tcl interpreter under
the hood;
At least it was the case last time I looked at Python. But if it's
still the case, I can easily understand efforts on the Python side to
bind to a more language-agnostic toolkit. It is a tribute to Tk's
excellence to have survived that long in the Python universe given
this burden.
Now, do we _want_ hegemony over scriptable graphical toolkits ? Even
without Tcl in TkInter's backpack ?
Or, on the contrary, do we cherish TkInter only as a successful Trojan
Horse waving our little flag just under the nostrils of the dragon ?
Third option, we may just want the "bundle" Tcl/Tk to keep its share
side-by-side with WxWidgets/Python.
But in that case, the toolkit may not be the only parameter of the
problem. The language and library count too. Just like the upper and
lower parts of an iceberg ;-)
Then, can we enumerate what criteria make the "bundle" WxWidgets/
Python preferred over Tcl/Tk for some people ?
-Alex
Keith Nash
<snip>
>
> A rule I'm reminded of by that function is Rule 5 from Rob Pike's list:
>
> "Rule 5. Data dominates. If you've chosen the right data structures
> and organized things well, the algorithms will almost always be
> selfÂevident. Data structures, not algorithms, are central to
> programming. (See Brooks p. 102.)"
>
> http://www.lysator.liu.se/c/pikestyle.html
>
> Anyway, I don't mean to be overly critical of E, but it seems clear that
> the lazy coding style hasn't changed for the better to me. If it works
> for you then that's good. I honestly hope you don't experience any
> strange bugs.
>
> My own lazy coding style is still evolving... I tend to prefer being
> lazy when it comes to having to fix bugs, rather than when writing the
> actual code and doing the design.
>
> I also have a lot to learn still. My Win32 code still isn't great...
> :-)
It's good that you've investigated the E17 code, as I merely ran it and
liked the demos. It's a shame if imlib2 has coding errors, as this is one
of the more mature components of E17 and is widely used by other projects.
The design phase of a project is clearly the most important - one reason E17
has been delayed for so long is that every so often they realise that they
need to rewrite a layer of their code from scratch.
Keith.
Eric Brunel
<alexandre...@gmail.com> wrote:
> One thing about Tkinter is that it needs a full Tcl interpreter under
> the hood;
> At least it was the case last time I looked at Python. But if it's
> still the case, I can easily understand efforts on the Python side to
> bind to a more language-agnostic toolkit.
IIRC, Perl has taken the other route by integrating tk at C level. I read
somewhere - maybe on this very newsgroup - that this wasn't a good idea,
as tk was designed from the start to be used within tcl, and removing the
tcl interpreter causes more problems than it solves. That seems to be the
main reason why the tk version included with Perl is usually far behind
the current one.
> It is a tribute to Tk's
> excellence to have survived that long in the Python universe given
> this burden.
Indeed.
[snip]
> Then, can we enumerate what criteria make the "bundle" WxWidgets/
> Python preferred over Tcl/Tk for some people ?
As for the language itself, I'd say that it's mainly a matter of
preference and "brain compatibility". Some people will just feel at home
with tcl; for others, it'll be Python. I doubt anyone can do anything
about that...
As for the GUI toolkit, here are the main reasons I saw on c.l.py why
people choose wxWidgets/wxPython instead of tk/Tkinter. The order is the
order of importance as I see it:
1/ Looks; tk has a reputation to be ugly.
2/ "Native" look'n'feel; this includes GTK look on Linux, even if KDE
users would certainly disagree...
3/ Wide widget choice out of the box, i.e. without extensions.
4/ Availability of graphical GUI designers.
- 1 & 3 should not be issues anymore with 8.5/ttk, but it will take time
to remove tk's "ugly poor toolkit" image from people's heads...
- 2 is a bit more complicated, since there won't be any "native" look
under Linux in 8.5 - whatever that means. (BTW, the ultimate "killer
feature" would be to detect which environment is setup for the current
user - KDE or Gnome - and dynamically choose to use QT or GTK with the
current theme. I doubt it can be done today...)
- 4 is mainly interesting when coming from environments like VBA, where
people are not used at all to actually code a GUI. I think that such a
tool would be interesting in the long term, with support for all the new
ttk widgets of course, and support for a wide range of languages (tcl of
course, Python, Perl, ...).
My [$£€¥] 0.02...
--
python -c "print ''.join([chr(154 - ord(c)) for c in
'U(17zX(%,5.zmz5(17l8(%,5.Z*(93-965$l7+-'])"
Larry W. Virden
> > WinAPI has 92 lines to achieve this trivial task, MFC needs 46, QT 23
> > and Tk finally 2. While it might not be always a factor of 10-50, Tcl/Tk
> > significantly makes it easy compared to other toolkits.
>
> That's a very good point. The more of a barrier you have to expression
> of your thought through code, the more bugs, you also usually have.
> It's also difficult to keep more than a few lines of code in mind
> perfectly at once, so less code and more abstractions allow us to be
> more productive with higher quality. Assuming the abstractions minimize
> side-effects.
Another thing that I can't prove with documented research, but
suspect, is that a toolkit like Tk is more likely to stay relatively
the same across version upgrades and operating system upgrades. The
more complex toolkits seem, to me, to have more points of potential
incompatibility. So changes in WinAPI has 40 times as many places
where the API might change incompatibly than Tk. Whether that plays
out in real life, I'm uncertain.
Larry W. Virden
> On Tue, 18 Dec 2007 23:38:14 +0100, Alexandre Ferrieux
>
>
> > Then, can we enumerate what criteria make the "bundle" WxWidgets/
> > Python preferred over Tcl/Tk for some people ?
>
> As for the GUI toolkit, here are the main reasons I saw on c.l.py why
> people choose wxWidgets/wxPython instead of tk/Tkinter. The order is the
> order of importance as I see it:
> 1/ Looks; tk has a reputation to be ugly.
> 2/ "Native" look'n'feel; this includes GTK look on Linux, even if KDE
> users would certainly disagree...
> 3/ Wide widget choice out of the box, i.e. without extensions.
> 4/ Availability of graphical GUI designers.
>
> - 1 & 3 should not be issues anymore with 8.5/ttk, but it will take time
> to remove tk's "ugly poor toolkit" image from people's heads...
As for problem 1 - until people are using ttk instead of tk for their
applications, things will continue to look the same. And I suspect
that merely replacing the tk command names with ttk command names will
be insufficient to make the application suddenly look "not ugly". So I
would say that perception of tk as "ugly" is probably going to be with
us for a while. After reading the posting to this thread about the
poster who had moved on from tcl/tk after looking at the tk demo,
perhaps it would be helpful if some of the talented community members
would add demos to the main tk demo program that demonstrated how to
get more contemporary looking programs making use of the option
database, etc. Having a big of flash in terms of demos would not only
be useful in the "advertising", but could provide new developers with
some tk "best practices" to improve the look of their applications.
As for problem 3 - is there a list of the widgets that are available
in wxWidgets? How does that list compare to the list of widgets in ttk
and tk?
> - 2 is a bit more complicated, since there won't be any "native" look
> under Linux in 8.5 - whatever that means.
I wonder what wxWidgets and some of the other toolkits do to provide
their "native" look.
Gerald W. Lester
> ...
> As for the GUI toolkit, here are the main reasons I saw on c.l.py why
> people choose wxWidgets/wxPython instead of tk/Tkinter. The order is the
> order of importance as I see it:
> 4/ Availability of graphical GUI designers.
>
> - 4 is mainly interesting when coming from environments like VBA, where
> people are not used at all to actually code a GUI. I think that such a
> tool would be interesting in the long term, with support for all the new
> ttk widgets of course, and support for a wide range of languages (tcl of
> course, Python, Perl, ...).
There have (and are) several.
The problem is that none gain much traction in the Tcl/Tk comunity because
they just don't make the process much easier or faster. In fact a number
make it harder if you want to use any widgets and/or megawidgets other than
those they "know" about.
In short, it is normally just as fast, if not faster, to just write the Tk
code yourself as to to use an IDE to lay out the GUIs -- this may be a
problem with Tk itself being too high level and easy to use.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
Donald G Porter
> As for problem 1 - until people are using ttk instead of tk for their
> applications, things will continue to look the same.
That's not correct.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
Eric Brunel
<Gerald...@cox.net> wrote:
> Eric Brunel wrote:
>> ...
>> As for the GUI toolkit, here are the main reasons I saw on c.l.py why
>> people choose wxWidgets/wxPython instead of tk/Tkinter. The order is
>> the order of importance as I see it:
>> ...
>> 4/ Availability of graphical GUI designers.
>> ...
>> - 4 is mainly interesting when coming from environments like VBA, where
>> people are not used at all to actually code a GUI. I think that such a
>> tool would be interesting in the long term, with support for all the
>> new ttk widgets of course, and support for a wide range of languages
>> (tcl of course, Python, Perl, ...).
>
> There have (and are) several.
With support for the new ttk widgets? I'd be interested to know which ones.
[snip]
> In short, it is normally just as fast, if not faster, to just write the
> Tk code yourself as to to use an IDE to lay out the GUIs -- this may be
> a problem with Tk itself being too high level and easy to use.
You know that, and I know that. But if you say that to anyone coming from
the world of IDEs and GUI builders, he'll look at you as if you suggested
to go back to programming in assembly language. This seems to be a
cultural issue, not a technical one...
Eric Brunel
wrote:
> I wonder what wxWidgets and some of the other toolkits do to provide
> their "native" look.
Well, as I understood it, wxWidgets is not exactly a toolkit, but a more
or less thin wrapper over the "native" toolkit. Since it was intended as
such from the start, they basically took the lowest common denominator of
all the toolkits they wanted to support, and just provided a unified API.
Except for very special cases (e.g wxWidgets on X, which was quite buggy
last time I looked), they don't actually implement any widget.
Kevin Walzer
> As for problem 3 - is there a list of the widgets that are available
> in wxWidgets? How does that list compare to the list of widgets in ttk
> and tk?
I'm not sure if there's a complete list anywhere. However, I have looked
closely at wxWidgets (via its Python bindings) over the years, and
here's my take on how it compares to Tk:
1. Complete widget set in one large framework. If you rolled Tk + Tile +
TkTreeCtrl + BWidgets + TkTable into a single framework, you'd come
close to the widget set that is offered in wxWidgets.
2. wxWidgets supports native printing out of the box, i.e. the printing
API hooks into native calls on Windows and Mac and (I presume) uses lpr
(or whatever libraries Gtk2 uses) on *Nix. This is a vexing problem with
Tk.
3. wxWidgets has much better built-in support for HTML rendering. It
wraps WebKit on the Mac, native MS libraries on Windows, and also has
its own, older implementation for other cases. I know there's tkhtml,
but the latest version (3) is still in alpha mode, and little work has
been done on building usable widgets (i.e. simple HTML displayer for
user help) on top of it.
4. Built-in drag and drop support that works on every platform. I know
about TkDND, but it isn't supported on the Mac and only partly works
under X if I recall correctly.
The drawback to this huge range of widgets is a much larger learning
curve, and (to my eye) an API that is more cumbersome and less elegant
than Tk. That's why I stick with Tk even though wxWidgets has some clear
advantages.
--Kevin
--
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
Bryan Oakley
> ...
> perhaps it would be helpful if some of the talented community members
> would add demos to the main tk demo program that demonstrated how to
> get more contemporary looking programs making use of the option
> database, etc. Having a big of flash in terms of demos would not only
> be useful in the "advertising", but could provide new developers with
> some tk "best practices" to improve the look of their applications.
I don't think we need more demos as much as I think the demo program
itself needs a little polish.
I have ideas and some code, but as usual I'm struggling to find the time
to make it a reality. For a brief time I was making a valiant effort to
get it done for 8.5, but it's just too late to do that (at least, I hope
8.5 is imminent!)
Since I've let the cat out of the bag, here' are some screenshots:
http://www.purl.org/net/oakley/goobe/index.html
I was inspired by hackityhack (http://hacketyhack.net/), a tool for
learning Ruby. The idea is to create a single starting point for
learning a little bit about the language -- a way to see demos, try some
interactive experimentation, maybe work through a tutorial. And, to show
how nice Tk can look.
I'm hoping to find some time over the holidays to work on this a little
bit more, but I don't know if I will. I may be having to look for a new
job by then :-(
--
Bryan Oakley
http://www.tclscripting.com
sp...@controlq.com
>
> I don't think we need more demos as much as I think the demo program itself
> needs a little polish.
>
> I have ideas and some code, but as usual I'm struggling to find the time to
> make it a reality. For a brief time I was making a valiant effort to get it
> done for 8.5, but it's just too late to do that (at least, I hope 8.5 is
> imminent!)
>
> Since I've let the cat out of the bag, here' are some screenshots:
>
> http://www.purl.org/net/oakley/goobe/index.html
>
> I was inspired by hackityhack (http://hacketyhack.net/), a tool for learning
> Ruby. The idea is to create a single starting point for learning a little bit
> about the language -- a way to see demos, try some interactive
> experimentation, maybe work through a tutorial. And, to show how nice Tk can
> look.
>
> I'm hoping to find some time over the holidays to work on this a little bit
> more, but I don't know if I will. I may be having to look for a new job by
> then :-(
Bryan,
A very impressive layout ... rounded corners, drop shadows, transparent
images, and a very clean look/feel ... hmmmm ... I'd steal that in a
heartbeat if I knew how you'd done it 8-).
BTW: what is going on in goobe3.jpg? you have a hor/vert scroll, rounded
(canvas? text?), and a greyed out portion on the left (listbox??) what
*IS* that???
Cheers,
Rob Sciuk
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups
Larry W. Virden
> Larry W. Virden wrote:
> > As for problem 1 - until people are using ttk instead of tk for their
> > applications, things will continue to look the same.
>
> That's not correct.
While there may be numerous changes within the code, when I run the
widget demo from Tk 8.4.7 and the one from Tk 8.5.0 on my sparc
solaris gnome platform, I see no obvious differences. Certainly
someone might respond with "oh, click on such and such a demo -
there's a pixel difference in the shadowing" or some type of respond.
But, from a user's perspective, what I see still is the same basic
thing.
Not that I've had a problem with Tk's look - I was fine with the beige
look, as well as the motif blue look.
Now, I _do_ see new widgets being demo'd in the newer widget program.
But that's outside the domain of this particular branch of the thread.
Keith Nash
Last time I tried Python and Tkinter (which was a while ago, things might
have changed now), the thing that surprised me the most was that Tkinter
run-time errors were reported with the Tcl/Tk stack trace that is very
familiar to us. A Python programmer would be required to know some Tcl/Tk
in order to discover the mistake he has made in his Python code. Many
people using language A would not want to learn an alien language B simply
to run a GUI toolkit, and it seems to me that this must contribute to the
impulse to integrate Tk at the C level, or migrate to a different toolkit.
Keith.
Bryan Oakley
> BTW: what is going on in goobe3.jpg? you have a hor/vert scroll, rounded
> (canvas? text?), and a greyed out portion on the left (listbox??) what
> *IS* that???
The rounded thing is just a ttk::frame customized with the technique
described at http://wiki.tcl.tk/20152.
The gray part on the left is a canvas, and is used for displaying line
numbers. Immediately to the right is a console widget in the spirit of
tkcon but lighter weight and therefore without as many bells and
whistles. It's a little megawidget I tinker with from time to time.
I think I need to make the gray lighter. Or, better yet, somehow ask the
theme for the right color, but I have no idea what question to ask. I'm
not sure if themes have the notion of "a slightly different background
color I can use for secondary information". Like most everyone else, I'm
still learning how best to take advantage of tile.
Oh, and thanks for the other kind words.
sch...@uni-oldenburg.de
Larry W. Virden wrote:
> On Dec 19, 9:56 am, Donald G Porter <d...@nist.gov> wrote:
> > Larry W. Virden wrote:
> > > As for problem 1 - until people are using ttk instead of tk for their
> > > applications, things will continue to look the same.
> >
> > That's not correct.
>
> While there may be numerous changes within the code, when I run the
> widget demo from Tk 8.4.7 and the one from Tk 8.5.0 on my sparc
> solaris gnome platform, I see no obvious differences. Certainly
> someone might respond with "oh, click on such and such a demo -
> there's a pixel difference in the shadowing" or some type of respond.
>
> But, from a user's perspective, what I see still is the same basic
> thing.
Might be minor things. AFAIK Jeff Hobbs changed some of the widget
defaults to a bit more modern looks.
At least it appears in the Tk release notes for 8.5b3:
* New Tk look and default fonts on X11.
[tk::classic::restore] to undo.
Michael
Kevin Walzer
> [snip]
>> Then, can we enumerate what criteria make the "bundle" WxWidgets/
>> Python preferred over Tcl/Tk for some people ?
>
> As for the language itself, I'd say that it's mainly a matter of
> preference and "brain compatibility". Some people will just feel at home
> with tcl; for others, it'll be Python. I doubt anyone can do anything
> about that...
I'm curious if there are any plans to integrate Tile into Python's core
Tk bindings (lib-tk). I maintain a binding at
http://tkinter.unpythonic.net/wiki/TileWrapper that was originally
authored by someone else, but I've been told that including this in the
core Python distro would be problematic because I'm not the original
author.
Michael Schlenker
license/copyright to get it included.
Michael
Donal K. Fellows
> I don't think we need more demos as much as I think the demo program
> itself needs a little polish.
To be quite frank, both are needed. Though it's polish that's needed
more at the moment, since I've done a new set of demos for 8.5 (mostly
covering Ttk, but also some other things too). There has been *some*
polishing applied to the overall demo framework (the demos themselves
should not be too polished; they've got to be simple and readable too)
but a lot more is needed.
Donal.
Eric Brunel
wrote:
> Last time I tried Python and Tkinter (which was a while ago, things might
> have changed now), the thing that surprised me the most was that Tkinter
> run-time errors were reported with the Tcl/Tk stack trace that is very
> familiar to us. A Python programmer would be required to know some
> Tcl/Tk
> in order to discover the mistake he has made in his Python code. Many
> people using language A would not want to learn an alien language B
> simply
> to run a GUI toolkit, and it seems to me that this must contribute to the
> impulse to integrate Tk at the C level, or migrate to a different
> toolkit.
That must have been quite a while ago indeed: I use Python/Tkinter since a
few years now and I never saw a tcl stack trace... The error messages
themselves do come from the tcl layer, but the tracebacks are Python's...
But you do need to know some tcl in order to fully understand what
happens, especially when errors occur. Here is an example:
>>> from Tkinter import *
>>> root = Tk()
>>> Label(root, test='Error').pack()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File
"/home/rtds/Tools/Python/bin/Linux/lib/python2.1/lib-tk/Tkinter.py", line
2269, in __init__
Widget.__init__(self, master, 'label', cnf, kw)
File
"/home/rtds/Tools/Python/bin/Linux/lib/python2.1/lib-tk/Tkinter.py", line
1764, in __init__
self.tk.call(
TclError: unknown option "-test"
Someone not familiar with tcl would probably have a hard time to
understand where this 'unknown option "-test"' comes from. And the best
way I found to use Python/Tkinter was basically to learn tcl/tk syntax and
how it is translated in Python. This first allows you to use the tcl/tk
man pages, and also to understand much better what happens "under the
hood".
But considering the effort that seems to be required to get rid of the tcl
interpreter to be able to integrate tk at C level, I really doubt it would
be a good idea... As I said earlier, Perl tried to do it, and it was never
quite satisfying apparently...
Eric Brunel
wrote:
> I'm curious if there are any plans to integrate Tile into Python's core
> Tk bindings (lib-tk). I maintain a binding at
> http://tkinter.unpythonic.net/wiki/TileWrapper that was originally
> authored by someone else, but I've been told that including this in the
> core Python distro would be problematic because I'm not the original
> author.
I don't know for sure, but what I can tell is that the Tkinter module has
always been kept up to date with the underlying version of tk. So as soon
as tcl/tk 8.5 is out and is officially supported in Tkinter, I see no
reason why Tile/ttk would be left out.
As for the wrappers you maintain, it's too bad there are these licensing
issues, since this would certainly speed up the integration of Tile/ttk in
Tkinter (always better to start from something existing that to do
everything from scratch...).