On 7/11/07, Kevin Walzer <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list
