wxPython Or Tkinter Advise PLEASEEEEEEEEE
reqhye72zux at mailexpire.com
Tue Aug 14 02:46:16 CEST 2001
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
> + runs on more different platforms (e.g. Mac) than Wx and is more
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,
> - 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
> + 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 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
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
> 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.
More information about the Python-list