On 11:37 Thu 24 Jan , Tor Lillqvist wrote: > > I am trying to run a simple(st) thread example in GTK with a > > windows-MinGW-Msys development environment > > Don't bother. You should not call GTK+ functions from multiple threads > on Windows. It won't work. There are deep technical reasons for this, > fixing it is in no way trivial. This has been mentioned several times > over the years on this mailing list.
I've tried to make gtk work with threads on win32 and linux for a long time now and I am finally proud to say, it is possible -- but, as Tor said, not trivial. Just some notes on how to make the first steps towards that: Write wrapper functions for any gtk operation you'd like to execute from threads in a way that the thread calls a glib's idle function which does the real gtk work. Additionally (!) you need to lock gtk/gdk access by the gds_threads_enter/leave functions -- since idle functions are not auto-locked by gtk (like signals are). When you get deeper into this topic you'll probably stuble accross the problem that idle functions are kind of a one way: you can launch an idle function e.g. to rename a label but what if you want to read out the current value of an entry widget? You want the result right when you ask, however the idle function comes back at some later point of time. The solution I took was not to wait for that idle function but create wrappers for the gtk widgets which keep the data and can be queried without asking gtk; this of course needs you to update the data whenever the user changes the real gtk widget. Good luck, it IS possible. Felix _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
