Python GUIs: Abandoning TkInter and welcoming wxPython?

[Michael P. Reilly]

From: "Michael P. Reilly" <arcege at shore.net>

Fredrik Lundh <fredrik at pythonware.com> wrote:
: Michael P. Reilly <arcege at shore.net> wrote:
:> But.. the argument over (these two) GUIs is not exactly a valid one.
:> Tkinter was written using the Tcl interface not the Tk/C API.  If
:> Tkinter was rewritten to use the C API, it probably wouldn't be slower
:> than wxPython.

: The interface is only part of the story; many complaints
: seem to come from the fact that Tk uses idle tasks to
: redraw things.  When an "expose" event arrives from
: the windowing system, Tk calls "after_idle", rather
: than redrawing the widget at once.  And idle tasks
: are only executed when there are no other events
: to take care of...

Hmm... something about that argument makes it circularly invalid.
Non-idle event a comes in, but must be handled after idle event d.
Event d can only execute when event a is taken care of.  Sounds like
deadlock to me. ;)

Events (from Tk_MainLoop) are handled by Tcl_QueueEvent and
Tcl_ServiceEvent (handled by Tcl_DoOneEvent).  Yes, it handles idle
events IF those are the only ones being requested to be serviced:
(taken from tcl8.0.5/generic/tclNotify.c, lines 668-672, in the
function Tcl_DoOneEvent)

        /*
         * If idle events are the only things to service, skip the
         * main part of the loop and go directly to handle idle
         * events (i.e. don't wait even if TCL_DONT_WAIT isn't set).
         */

Otherwise the first thing called is Tcl_ServiceEvent.  Now yes, this
means that when it is servicing idle events, it will not check to see
if there are any pending events, but I see that as a different issue.

In fact, what might be objectionable, is there are two Tcl_ServiceEvent
calls (one on either side of the Tcl_WaitForEvent) before the
Tcl_ServiceIdle call, delaying the "do_idle" even more.

: Tk also uses double buffering for all widgets, which is
: quite expensive, especially since Tk allocates a new
: buffer for each update :-(

Yes, that could be a problem, but see what I mean down below about
additional layers.

:   In fact, since wxPython has to go thru extra layers, it
:> would probably be slower (Tk/C is written on the native API on all the
:> platforms).

: What native API?  As of 8.0, Tk still emulates all widgets
: except the scrollbar, and use a somewhat ineffective
: X emulation layer for graphics.  AFAIK, they haven't
: changed that in 8.1...

Exactly, Tk is using the native API: X11 (not Motif, not Xt, no
emulation other than its own), Windows, MacOS.  wxWindows requires GTK
or Motif on UNIX, requiring another level of software.  Motif is
licensed (but most vendors have gotten around that.  GTK+ 1.2.3 is 2.58
Mb with monthly updates (they do kindly give patch updates tho).

Also, Tk was developed on X11, where the window object created is
stored in the X server (another process), not in the application.  It
is standard practice to keep your own information about the objects you
request creation of.  This is no different from what wxWindows would
have to do using GTK or Motif, both using X11 (except that wxWindows
would probably have its own information as well as similar information
would be stored for widgets created from either GTK or Motif).

I'm not saying that Tk is the greatest thing since sliced bread, just
that it may not be as off-kilter as people think.  Tkinter is off in
that is uses the Tcl/Tk interpreter instead of the Tk/C API (but I
for one am not complaining ;).

  -Arcege