We have a Python application using PyGTK, which fires up a second thread for the GUI and gtk.main() while main processing happens in the Main thread. Main is responsible for much of the actual drawing of the GUI, while the secondary thread is responsible for picking up actions on the GUI and prodding the main thread into the appropriate responses. This has been working beautifully with accessibility disabled, and under older versions of GTK.
However, we're running into the problem of the application freezing when accessibility is enabled on newer systems (Ubuntu 8.10+ as far as I can tell.) I've narrowed it down to which thread gtk.main() is executed in. If it's the main thread, there are no problems. If it's in the secondary thread, then as soon as the window loses focus, it hangs. Not only does it hang, but the idle functions that I've registered with gobject.idle_add(...) will get through one more iteration and then never execute again. It looks like something is deadlocking in glib's or gtk's internals when this happens. Is running in a secondary thread simply not allowed at the moment? I'd prefer to find a solution that allows us to keep our current structure rather than juggling our threads, but if it must be changed, that's acceptable. At the very least, I'd like to understand better the technical details of how GNOME accessibility is interacting with our program. Thanks for your time, -Tim _______________________________________________ gnome-accessibility-list mailing list gnome-accessibility-list@gnome.org http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
