wxPython vs. Tkinter event loops

[Chris Mellon]

On 7/11/07, Kevin Walzer <kw at codebykevin.com> wrote:
> I'm porting a Tkinter application to wxPython and had a question about
> wxPython's event loop.
>
> The Tkinter app provides a GUI to a command-line tool. It gathers user
> input, and opens an asynchronous pipe to the external tool via
> os.popen(). Then, it dumps the output from the external process into a
> text display. Although threads are often recommended for use with GUI
> apps,  I am able to keep the GUI responsive with Tkinter's event loop,
> i.e. with regular calls to self.update(); I am still able to update the
> GUI as needed. When I tried the same functions using threads, I noticed
> no measurable improvement in application responsiveness or performance.
> Thus, the application currently runs in a single thread and is updated
> via Tkinter's event loop only.
>
> Does wxPython's event loop function as smoothly as Tkinter's with an
> asynchronous process, i.e. is the wx.UpdateUIEvent() class analogous to
> Tkinter.update(),

No. It provides a totally different purpose - it's an idle event thats
used to do things like ensure that menu items and toolbar buttons are
kept in sync.

>or are threads absoutely essential to keeping a wx GUI
> updated with a long-running background process?

No again. wxPython provides a Process class for executing external
applications and providing events in response to input, app exit, and
similar. You can also implement it in a similar way to your Tkinter
implementation, but backwards - poll the pipe repeatedly using
wx.CallAfter or wx.CallLater calls.