Tim Evans wrote:
> GTK+ 2.14.4
> PyGObject 2.14.2
> PyGTK 2.12.1
Mine is
GTK+ 2.20
PyGObject 2.21.2
PyGTK 2.17.1
A few things about your changes confused me -
1. You call glib.idle_add, but never called glib.threads_init - won't
this break on Linux?
2. You use BOTH gtk.gdk.lock and glib.idle_add - but surely one of
these is superfluous, since glib.idle_add executes the function in the
main loop, where the lock is already acquired?
Anyway, I came up with a different, simpler way, but I don't know
enough to say if it will never fail. I can't push to github from here,
but basically it's the same as my first example[1] but with this main
block for controller.py:
----
if __name__ == "__main__":
import glib
import gtk.gdk
gtk.gdk.threads_init()
glib.threads_init()
view = MyView()
model = MyModel()
controller = MyController(model, view)
with gtk.gdk.lock:
LaunchUI(view)
----
Works on both win32 and linux, using glib.idle_add throughout. I was a
bit worried that trying to acquire the gtk.gdk.lock from the main
thread would cause problems under linux as per [2], but it works fine.
Lessons learnt:
1. Call gtk.gdk.threads_init() BEFORE glib.threads_init() (otherwise
glib.idle_add won't work)
2. Call them both before you do anything else
3. Start the main loop in the gtk.gdk.lock context manager or
surrounded by gtk.gdk.threads_enter/leave()
Thanks for everyone's patience - I rarely have to develop under win32,
so I'm not really aware of these gotchas.
- Jason
[1] http://github.com/detly/gtk-async-test
[2] http://faq.pygtk.org/index.py?req=show&file=faq20.015.htp
_______________________________________________
pygtk mailing list [email protected]
http://www.daa.com.au/mailman/listinfo/pygtk
Read the PyGTK FAQ: http://faq.pygtk.org/
