On Wed, Feb 04, 2004 at 01:10:27PM -0800, Jeff Bowden wrote:
John K Luebs wrote:
On Tue, Feb 03, 2004 at 08:33:11PM -0500, Dave Aitel wrote:For general threading this is true, but most GUI threading can be reduced to background "producer" threads which feed results to a designated GUI "consumer" thread via a python Queue object. This sort of architecture is often easier to understand and debug than ad-hoc threading.
Is there a known bug, possibly related to threading (I just thread enabled by app), that turns the fonts to white on white, in pyGTK (latest python and pyGTK) on Windows XP?
Probably not related to the topic of this thread, but important for would be multi threaders on Windows. It is almost not possible to use multiple threads safely with gtk on Windows, even if you lock properly. Xlib doesn't care about threads, as long as you serialize your calls properly. Windows is fundamentally different. When you create a window, the window is married to the thread that called CreateWindow. This means it is impossible to use gtk/gdk from different threads even if you lock properly without looking under the gdk hood to see if the underlying Win32 API calls are "safe". You gotta love Windows. As has been discussed on the gtk-devel list a solution is to have GDK create a single thread dedicated to Window creation, and have functions post thread messages to this thread. This would not be trivial to implement.
This is a good point, and I agree completely. I just wanted to point out
that even if you lock correctly and have a program that is correct for the X11 port that you are not guaranteed that it works for the Windows port due to fundamental limitations in the Win32
windows/message queue design. The general work around given above is a
cure that is probably worse than the disease (which is why no one is
champing at the bit to implement it), because arguably well designed applications shouldn't run into the problem in the first place.
--jkl
I'm confused. How should I design my pyGTK application to avoid this issue?
-dave
_______________________________________________
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/
