Tkinter vs wxPython: your opinions?

[cbarker at jps.net]

Hi all,

There have been a lot of good comments in this thread so far, and no
nastiness (this really is a great newsgroup). I have a few things to
add.

1) while tkInter works on the Macintosh, it is not well supported there,
and a lot of us have problems with it. wxWindows is in pretty good shape
on the Mac, and a wxPython wrapper is supposed to be in the works,
although that has been said for a long time now. I still have hope.

2) wxPython is a very thin wrapper around wxWindows which is a C++
application framework. This is a good thing for two reasons:
 - The wrapper code can all (or most anyway) be generated with SWIG, so
wxPython can be updated almost as fast as wxWindows. This is nice since
wxWindows is under active development, and any bugs fixed in wxWindows
can propogate very quickly to wxPython
 - You only need one set of Docs. This is also good for the above
reasons. The docs are about C++ with a few Python notes. This is pretty
off-putting for first timers, but I found that once I got past that
first steep part of the learning curve, I've found it to be no problem.
I have never written a C++ program, and only a few smal C programs.
Python programmers can pick it up easily, I assure you.

The downside of the close link between the C++ and Python is that there
are a number of things that are not very Pythonesque. The most obvous
thing that comes to mind is event tables. I find myself writing three
lines of code for what could be done with one (asd far as I can tell) an
example (from the demo)

ID_ABOUT_MENU = 200
help_menu.Append(ID_ABOUT_MENU,
                 "&About",
                 "More information About this program")
EVT_MENU(self, ID_ABOUT_MENU, self.OnAbout)


When would I want a menu item , without an function attached to the
EVT_MENU ? IF i want tou use a name to label the itemI need another line
of code to do that.

I'd like to see:
help_menu.Append(ID_ABOUT_MENU,
                 "&About",
                 "More information About this program",
                 callback = self.OnAbout)

That would make a lot more sense, but frankly, it's really just a small
annoyance once you get used to it.

3) The tk canvas is a wonderful thing, and something like it is sorely
missed in wxPython. Fortunately, a wxCanvas is in the works. It is a
work in progress, but it looks pretty promising stay tuned, and If
you're a C++ programmer, help out!

4) Another plus of wxPython is that it is based on a C++ application
framework,and as such can be used with a Python interpreter embedded in
a wxWindows app. What is done in Python, and what is done in C++ can
become very fluid.

I have also written a Vector object Canvas in wxPython that makes things
much easier for me. when it's a little more polished, I intend to
release it, but if you're intersted, send me a note.

4) wxPython Sizers look to be a very powerful way to set up a bunch of
controls, particularly dynamically. They are, unfortunaely, not all that
well docuemnted (at least not in a learn to use them format), and a bit
harder to grasp that tk's pack. However, while I could whip together a
quick dialog with pack very easily at my first attempt, I found that
when things got a little more comples, it took a long time to figure out
all the nested frames that I had to use. wxPython sizers look like they
will be much easier for this once I have them figured out.


In summary, it seems to be a common thread that the learning curve for
tk is less steep at the begining, but once you get the hang of wxPython,
people find they are just as (if not more) productive. I think a good
canvas widget will really bridge the gap, it is a real show stopper for
some folks.

Another note I'd like to make is that the wxWindows developers are very
supportive of wxPython. When questions and bugs crop up in wxPython that
are really wxWindows issues, we always get a good response.


Another final Big comment:

While this discusion was started by someone that is trying to choose a
toolbax NOW, if seems that in general, the discussion is always about
what strengths or weeknesses tkinter, wxPyton, PyQT, fxPy, etc. have
now. What no one seems to be talking about is what Python needs in the
way of a GUI toolbox Every gui option for Python is a wrapper around
something that was intended to be used for something else. The result is
that none of them really feel Pythonesque, and usually suffer from
perfomance issues as well.

Is anyone considering a real native Python GUI option? This, of course
would be a monsterous effort to do from scratch, but it wouldn't
neccesarily have to be started from scratch, It could start as a
thick(rather than thin) wrapper around an existing toolbox, with the
goal that pieces of it would be converted to more "native" code as we
wnet along. A great final goal would be a C++ application framework that
used the native Python datatypes, so you could have easy back and forth
between the languages. What was implimented in C++ or Python could be
very fluid. Perhaps a melding of wxWindows (or Fox, or whatever) with
Cxx. Anyway, that's my fantasy.

-Chris












Sent via Deja.com
http://www.deja.com/