Back in January, James said this: > The threading in pygtk-1.99.x is not quite solid at the moment (which is > why you need to manually enable it during configure). If you are having > troubles, I recommend you try the latest CVS version.
(http://www.mail-archive.com/[EMAIL PROTECTED]/msg05333.html) Is this still the case? I'm working on an application that just cries out for threading (a CD ripper -- operations like ejecting the CD, reading the TOC, querying the CDDB etc. should all be done in the background), and it doesn't quite work. Details: if I restrict background threads so they make no GTK/GDK calls, everything seems to work fine. But that makes it hard to, eg., make the "Eject" button insensitive while the drive is ejecting. (At least under Linux, the "eject CD" ioctl() doesn't return until the drive door is fully open.) I'm sure it's possible to make this happen by cooking up a protocol between the eject thread and the main thread, but it would be so much cleaner if the eject thread just did this: eject_button.set_sensitive(False) gtk.mainiteration() cdrom.eject() eject_button.set_sensitive(True) Unfortunately, if I make any GTK calls in the background thread, the application freezes. Even if I call gtk.threads_enter(), it still freezes -- it just happens in the threads_enter() call, rather in the first widget-twiddling call. So, first question: is threading support stable/reliable yet? (I'm running Debian unstable with libgtk 2.2.1-3 and pygtk 1.99.16-1.) If so, can anyone tell me how to do it right, ie. how to write a background thread that manipulates the GUI? Thanks -- Greg -- Greg Ward <[EMAIL PROTECTED]> http://www.gerg.ca/ Laziness, Impatience, Hubris. _______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
