Matthias Kaeppler wrote:
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.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).
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.