Matthias Kaeppler wrote:
Tim Janik wrote:
you can use gtk functions from any thread, as long as you take care to
acquire the gtk lock around any gtk functions:
GDK_THREADS_ENTER ();
fire up dialog here.
GDK_THREADS_LEAVE ();
Yep, I could do that. However I was told that the cleaner approach is
to use a dispatcher (Glib::Dispatcher) and make sure that the GUI is
only modified in the Gtk main thread. I also noticed strange behavior
when using these functions when I didn't wrapped each and every call
in them (making my code extremely ugly since I quite often need to
make GUI calls from other threads).
You can wrap all the thread's code in the ENTER/LEAVE call, but then you
must free the lock before any time-consuming operation (file I/O,
synchronizations and so on) and aquire it again once the operation is done.
Besides, this lock/unlock thing doesn't seem to be the whole story.
For example, my program will only lock up when I create and show a
modal dialog inside the second thread, while the dialogs I use to
display transfer progress (which were created--but not shown!!--in the
main thread) never crash my program when showing/hiding them! That
just doesn't make sense.
When the lockup actually happens? You mustn't use the lock in the
dialog's event handlers, 'cause they get called in context of the main
thread with the lock already acquired.
Since Nautilus, as I pointed out, also doesn't seem to suffer from
this inter-thread GUI problem, I am sure I am missing something. I
thought maybe someone here knows since I was pretty sure that the
Nautilus developers read this list.
Nau is open source, isn't it? You could take a look at the sources and
find out everything you need to know ;)
If you show a part of the code you're talking about, probably you get a
more helpful advice on it.
wbr, Dmitry.
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
