On Thu, 2013-06-13 at 08:59 +0100, jcup...@gmail.com wrote: > Hi Kip, Hey John,
> There are two easy ways to do a long operation in Python. > > First, with idle_add(). Your callback should run for no more than 50ms > or so before returning. If you need to do more work than that, just > wait to be called again. Do not process events, you can leave that up > to the main loop. This style is handy for non-blocking, background > tasks that don't need interaction from the user. Ok, fair enough. I didn't know idle callbacks were intended to be used only for fast non-blocking tasks. > Secondly, with a regular loop that takes control for a long period. > You can keep the GUI alive by processing events, as you say above. > This style is better for modal actions that either block the GUI or > may require interaction. So as I mentioned I tried abandoning the idle_add() approach and instead relied on calling the worker function directly. > It sounds like you have done both at the same time, which seems > confusing to me. I'd make a pure 2) one. If the GUI doesn't refresh, > you probably have a bug in your code somewhere. I do this by calling the long job function directly from within the GtkAssistant's "prepare" signal callback immediately. The problem is that the GUI doesn't refresh throughout the duration of the long job, even though I do explicitly pump the message queue by calling _updateGUI() method regularly: # Update the GUI... def _updateGUI(self): # Update GUI... (...) # Flush the event queue so we don't block... while Gtk.events_pending(): Gtk.main_iteration() The GUI just appears to hang on the previously displayed page in the assistant and doesn't advance to the one that actually should be visible following the "prepare" signal callback. -- Kip Warner -- Software Engineer OpenPGP encrypted/signed mail preferred http://www.thevertigo.com _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list