Re: [pygtk] pygtk and threads.

2005-01-24 Thread Antoon Pardon
On Mon, Jan 24, 2005 at 11:59:45AM +0100, Rafael Villar Burke wrote: > Antoon Pardon wrote: > > >Well it's not a matter of doing my self a favor but a matter of correct > >information and a matter of pygtk not making things more complicated as > >they should. > > > >1) The correct information part

Re: [pygtk] pygtk and threads.

2005-01-24 Thread Antoon Pardon
On Mon, Jan 24, 2005 at 11:16:29AM +, Gustavo J. A. M. Carneiro wrote: > Hello. > > Your arguments may be valid (or not, that's not the point here), but: > > - PyGTK just wraps Gtk+, we should _not_ change gtk+ API semantics, > because having a similar API between PyGTK and Gtk+ is

Re: [pygtk] pygtk and threads.

2005-01-24 Thread Gustavo J. A. M. Carneiro
Hello. Your arguments may be valid (or not, that's not the point here), but: - PyGTK just wraps Gtk+, we should _not_ change gtk+ API semantics, because having a similar API between PyGTK and Gtk+ is a feature we should preserve for people that like Python just for prototyping and lat

Re: [pygtk] pygtk and threads.

2005-01-24 Thread Rafael Villar Burke
Antoon Pardon wrote: Well it's not a matter of doing my self a favor but a matter of correct information and a matter of pygtk not making things more complicated as they should. 1) The correct information part is because I'm thinking about writing a tutorial on using threads with pygtk. If you ge

Re: [pygtk] pygtk and threads.

2005-01-24 Thread Antoon Pardon
On Fri, Jan 21, 2005 at 09:44:46AM -0500, Dave Aitel wrote: > Honestly, you save yourself days of debugging if you stick to a "GUI > thread" and have all real work done in other threads. This requires a > GUI Thread "queue" that you have it clean when it gets a chance. This is > how CANVAS works

Re: [pygtk] pygtk and threads.

2005-01-23 Thread Tim Evans
Chris Lambacher wrote: Hi, Threading does not work quite like that. You don't have to call threads enter and threads leave before every funtion call, only when you are making pygtk calls from another thread. You would generally have: if __name__ == '__main__': gtk.gdk.threads_init() gtk.gd

Re: [pygtk] pygtk and threads.

2005-01-21 Thread Dave Aitel
Honestly, you save yourself days of debugging if you stick to a "GUI thread" and have all real work done in other threads. This requires a GUI Thread "queue" that you have it clean when it gets a chance. This is how CANVAS works, and we work on anything from *BSD to Windows this way. :> Just my

Re: [pygtk] pygtk and threads.

2005-01-21 Thread Antoon Pardon
On Fri, Jan 21, 2005 at 08:28:58AM -0500, Chris Lambacher wrote: > Hi, > > Threading does not work quite like that. You don't have to call > threads enter and threads leave before every funtion call, only when > you are making pygtk calls from another thread. I didn't write you had to put every

Re: [pygtk] pygtk and threads.

2005-01-21 Thread Chris Lambacher
Hi, Threading does not work quite like that. You don't have to call threads enter and threads leave before every funtion call, only when you are making pygtk calls from another thread. You would generally have: if __name__ == '__main__': gtk.gdk.threads_init() gtk.gdk.threads_enter()

[pygtk] pygtk and threads.

2005-01-21 Thread Antoon Pardon
I have been looking at the documentation of the gtk.gdk.threads_... functions. (*) at: http://www.pygtk.org/pygtk2reference/gdk-functions.html There I read under gtk.gdk.threads_init: | Theoretically any time a thread calls a PyGTK method or function it | should bracket the call with the gtk.gdk