Hey list,
My GtkAssistant on one page in particular performs a long operation
which would otherwise block the GUI from refreshing, if it were not for
intermittent...
while Gtk.events_pending():
Gtk.main_iteration()
The application is single threaded and performs all operations from the
main loop. I had originally broken this into a separate worker thread,
but Python threads, the VM, GObject / GLib, and Gtk+ do not always seem
to play well with each other when using threads.
To start the long work, the "prepare" signal is captured in my
assistant and the long job ("startDiscVerification()") method is
enqueued via GObject.idle_add() in the onPrepare() method. As mentioned
previously, intermittently the function updates the GUI via the above
technique.
<http://pastebin.com/fcTDrsu9>
This all works fine, however, when the long job completes, the entire UI
hard locks and does not appear to be responsive. It's almost as though
the main loop totally dies or something. Trying to look for a stack
trace, if I'm using pdb correctly, it looks like it's left hanging on
this:
>
/usr/lib/python3/dist-packages/gi/overrides/GLib.py(629)<lambda>()->False
-> return (lambda data: callback(*data), user_data)
I've heard some mention that you should not pump the message queue (e.g.
Gtk.main_iteration()) from within an idle callback. However, if I don't
do this, the GUI is frozen during the long job. If I call the long job
(startDiscVerification()) from within the "prepare" signal callback
immediately, as opposed to en-queueing via GObject.idle_add(), then the
GUI doesn't refresh throughout the duration of the long job, even though
I pump the message queue.
Any help appreciated.
--
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
