On Wed, 2004-06-23 at 08:30, Antoon Pardon wrote: > On Tue, Jun 22, 2004 at 07:27:33PM -0400, dave wrote: > > I personally believe the best way is to have a socket or pipe as a > > trigger, and do all your gui stuff in one main thread, triggered by a > > socket connection. Immunity does this on both win32 and linux to avoid > > all the problems with threading entirely. If I get some time, I'll write > > a quick paper on it and give some good examples. > > > > -dave > > Well I use idle_add if I want all gui stuff to be done in the main > thread. > > What I would prefer is somekind of gtk.Queue class that would > work like the queues from the Queue module but for which it > would be possible to register a handler with queue_add_watch > just like you can register a handler for io with io_add_watch. > > Now I more or less simulate this by thinking of the idle_add > like a Queue.put() and the call of the registered function > like a Queue.get(). > > > BTW, In trying to understand how to work with threads, I have > written number of programs that all do the same but which > are organised differently in how the threads cooperate. > (They look a bit like the wxPython thread demo) > > Allthough they aren't finished yet, they could be usefull > as demo's. Do demo programs need to follow some guide lines? > Does someone has some place to put them? Can I put them on > the list? Maybe someone else can give them a look over > since I consider my self a gtk-newbee, so maybe somethings > I do could be done better? I for one would like to see them :) A threading tutorial is always nice. Making demos out of the most common concurrent patterns would also be interesting.
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
