Python GUIs: Abandoning TkInter and welcoming wxPython?

[arcege at shore.net]

From: arcege at shore.net

Fredrik Lundh <fredrik at pythonware.com> wrote:
: Michael P. Reilly wrote:
:> 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. ;)

: hmm.  I thought I'd meant that idle tasks kept piling up
: when the windowing system generates a lot of events
: at once (like when you're redrawing an entire system).
: instead of redrawing everything at once, Tkinter waits
: until the window event queue is empty...

Yes, indefinate postponement is a problem with the current definition
of Tcl_DoOneEvent.  But idle tasks are for when the event loop is idle,
and indefinate postponement is the standard, accepted trade-off for
that.  Timer handlers exist for handling more time critical actions.

You had made the comment(s) earlier in the thread:
> 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...

This lead me to think that you meant windowing events (such as expose)
were handled as idle tasks and I don't see this (MotionNotify events,
yes, not all others are handled by Tcl_QueueEvent).  Hence my comment
about the deadlock.

  -Arcege