i use gtk.gdk.threads_init() as well, and don't wrap the main loop in threads enter/leave, all seems to work well...
hope it helps, felix On 9/23/07, John Stowers <[EMAIL PROTECTED]> wrote: > > > > > Q. Anything I missed, or any suggestions. Is there a > > comprehensive list/scheme on how to write a MT pygtk > > app? > > > > After writing a few threaded pygtk programs [1][2] I have settled on > one approach which I consistently use, I try not to mix the > threads_enter and threads_leave with idle_add, I use the latter > exclusively. > > I basically override gobject.emit() and always emit on the idle > handler. Any limitations where you want to touch the GUI from other > threads and feel you cannot use signals are usually representative of > design omissions and I find they can usually be rectified by > restructuring things into a more OO form and deriving from the code > shown below [3]. > > Anyway, good luck, > > John > > [1] http://www.conduit-project.org/ > [2] > http://www.johnstowers.co.nz/blog/index.php/2007/03/12/threading-and-pygtk/ > [3] > > class IdleObject(gobject.GObject): > __gsignals__ = { > "foo" : ( > gobject.SIGNAL_RUN_LAST, gobject.TYPE_NONE, []) > } > def __init__(self, emitOnIdle=False): > gobject.GObject.__init__(self) > self.emitOnIdle = emitOnIdle > > def emit(self, *args): > """ > Override the gobject signal emission so that signals > can be emitted from the main loop on an idle handler > """ > if self.emitOnIdle == True: > gobject.idle_add(gobject.GObject.emit,self,*args) > else: > gobject.GObject.emit(self,*args) > _______________________________________________ > pygtk mailing list [email protected] > http://www.daa.com.au/mailman/listinfo/pygtk > Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/ >
_______________________________________________ pygtk mailing list [email protected] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
