wxPython Or Tkinter Advise PLEASEEEEEEEEE

[Robert Amesz]

Russell E. Owen wrote:

> They both work, so I think you'll do fine either way.
> 
> Here are some considerations. I have used Tk much more than Wx, so
> have much less to say about Wx. Contributions would be most
> welcome. 
> 
> Tk:
> + runs on more different platforms (e.g. Mac) than Wx and is more
> mature

I don't know all that much about Tkinter, but from what I've seen 
Tkinter programs are somewhat smaller than their wxPython counterparts. 
However, it seems that from wxPython you have more control over some 
things. Also, wxPython seems to have a richer set of controls and 
standard dialogs than Tkinter, presuming Fredrik Lundh's reference in 
his tutorial is anywhere near complete.



> + has a nice Canvas widget

>From what I've read, a Canvas is just something you can draw on. You 
can do that easily on a wxWindow by making a handler for paint-events: 
blitting images, writing text, drawing, you can do it all in such a 
handler. However, don't expect C++ speed from a Python paint-handler.


> + nice file event support for networking applications
>   (I don't know about this on Wx)

Actually, I don't even know what you mean by 'file event'.


> + tons of flexibility for button sizes, font sizes, etc.
"Me 2", states wxPython boldly.


> + lots of nice layout options
"Me 2", snickers wxPython knowingly.


> + lots of books are available on Tk, and at least one on Tkinter
"Ah, there you have me", sighs wxPython forlornly.

Considering the number of times people ask for a book on wxPython, this 
could be winner if someone were to write it. If I considered myself 
anywhere near an expert on the subject, (and had the time), I might 
feel tempted to do so. But I'm just a dabbler...


> - is fairly slow (you end up running a Tk interpreter as well as
> the Python interpreter)
> - has brain-dead support for copy and paste

That's something which wxPython knows how to handle. (Drag'n'Drop too, 
BTW.)


> - has somewhat clumsy mapping from Pyton to Tk. For instance a lot
> of times you end up with a Tk name that you have to then convert to
> a widget before you can do anything with it. I suspect much of this
> is because Tk is not object-oriented.
> - bizarre inconsistencies in Tk -- different widgets often have 
> different ways of doing the same things
> - lack of a nice multi-line text display widget (that the program
> can write to but users cannot alter the text); this is a famouse Tk
> FAQ, to which the answer is to (gag) enable updates (which means
> the user can manipulate the text), write your text, then disable
> updates again - some things are broken on the Mac (menus, file
> events) 
> 
> Wx:
> + Wx is reported to be much faster than Tk
> + Python is basically an equal partner to the C++ code, and Wx is 
> object-oriented, so the mapping appears to be nicer from Python to
> Wx 

> - Wx relies on unique ID numbers to describe events (gag)

Not really. Unique ID number are only needed if you want to call 
different event-handlers for the same event-type _from the same 
window_. Normally parent windows handle some of the events for/from 
their children, which usually controls (e.g. buttons). If those 
controls have the same ID number they have to share the same event 
handler(s). I think it is possible to determine the target window for 
an event without knowing the ID number, but that could be tricky for 
several reasons.

Having said that, wxPython will generate unique ID's for its window 
objects if you set those to -1 (often, that's the default value 
anyway), and it's dead easy to get the ID from a window.

A convenient (well, I use it) idiom would be something like this, as 
part of the __init__() function of the parent window:

   self.a_button = wxButton(self, -1, "Press Me")
   EVT_BUTTON(self, self.a_button.GetId(), self.OnClickEventFunction)

So, doing away with the IDs and associating the event handler directly 
with the button-reference would mean we could lose the '-1,' in the 
first line and the '.GetId()' in the second. Not a huge saving, 
although it would look cleaner. Furthermore, using duplicate ID numbers 
can sometimes be helpful: a toolbar-button, for instance, can be 
handled by a menu event handler if the IDs are the same.


> - no current Mac releases, though if you are willing to check code
> out of CVS you can probably get the Mac stuff running (depending on
> what day you check it out)
>
> o Wx includes a lot of tools that Python already has; I'm not sure
> how this overlap works out

To be honest, I'm not too sure Robin Dunn bothered to python-wrap all 
the wxWindows stuff for which there's already something in the Python 
library. I don't think it's a great issue, unless you specifically use 
wxPython as a rapid prototyping system for wxWindows.


> Also, if you care, Wx looks more like Windows, whereas Tk looks
> more like unix X.

WxWindows (and consequently wxPython) tries to get the look-and-feel of 
the platform it's running on, by using native widgets as much as 
possible. On Windows the native look-and-feel is excellent, that's 
certainly true.


> The Python 2.1 Bible, by Brueck and Tanner, (a very nice book) has
> a short chapter on WxPython which should get you going. It also has
> a short chapter on Tk, but it sounds as if you may be far enough
> along to not need that.

The best source of examples and a good place to pinch some code from is 
the wxPython demo.


Robert Amesz