Re: GUI freeze and long blocking operation

[Kip Warner <kip thevertigo com>]

On Thu, 2013-06-13 at 08:59 +0100, jcupitt 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