Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » GTK+
  • » Opening dialogs outside the Gtk thread? [RSS Feed]

#1 Oct. 27, 2005 22:51:48

Matthias K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


Hi,I want to display a message dialog from a thread B running parallel tothe Gtk main thread A (it's a thread invoked by the async transfermethods from gnome-vfs). When running the dialog directly, the programlocks up, which is what I expected since Gtk is not thread safe.So I downloaded the nautilus source code to see how they do it but theyopen the dialog directly in a function which is not called from the Gtkmain thread using eel_run_simple_dialog() (I also downloaded the eelsources and I couldn't find anything related to thread tunneling anddialogs in the respective functions).How come it works for them without dispatching the call to the mainthread, but not for me? I already started to implement the mechanics tosynchronize both threads, but it's really a lot of code just to show adialog from a second thread... Am I missing something?Regards,
Matthias

_______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

#2 Oct. 27, 2005 22:58:57

Tim J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


On Thu, 27 Oct 2005, Matthias Kaeppler wrote:Hi,I want to display a message dialog from a thread B running parallel to theGtk main thread A (it's a thread invoked by the async transfer methods fromgnome-vfs). When running the dialog directly, the program locks up, which iswhat I expected since Gtk is not thread safe.So I downloaded the nautilus source code to see how they do it but they openthe dialog directly in a function which is not called from the Gtk mainthread using eel_run_simple_dialog() (I also downloaded the eel sources and Icouldn't find anything related to thread tunneling and dialogs in therespective functions).How come it works for them without dispatching the call to the main thread,but not for me? I already started to implement the mechanics to synchronizeboth threads, but it's really a lot of code just to show a dialog from asecond thread... Am I missing something?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 ();Regards,
Matthias---
ciaoTJ
_______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

#3 Oct. 28, 2005 09:23:37

Matthias K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


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 touse a dispatcher (Glib::Dispatcher) and make sure that the GUI is onlymodified in the Gtk main thread. I also noticed strange behavior whenusing 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 GUIcalls from other threads).Besides, this lock/unlock thing doesn't seem to be the whole story. Forexample, my program will only lock up when I create and show a modaldialog inside the second thread, while the dialogs I use to displaytransfer progress (which were created--but not shown!!--in the mainthread) never crash my program when showing/hiding them! That justdoesn't make sense.Since Nautilus, as I pointed out, also doesn't seem to suffer from thisinter-thread GUI problem, I am sure I am missing something. I thoughtmaybe someone here knows since I was pretty sure that the Nautilusdevelopers read this list.Regards,
Matthias

_______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

#4 Oct. 28, 2005 10:09:29

Dmitry K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


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 isto use a dispatcher (Glib::Dispatcher) and make sure that the GUI isonly modified in the Gtk main thread. I also noticed strange behaviorwhen using these functions when I didn't wrapped each and every callin them (making my code extremely ugly since I quite often need tomake GUI calls from other threads).You can wrap all the thread's code in the ENTER/LEAVE call, but then youmust 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 amodal dialog inside the second thread, while the dialogs I use todisplay transfer progress (which were created--but not shown!!--in themain thread) never crash my program when showing/hiding them! Thatjust doesn't make sense.When the lockup actually happens? You mustn't use the lock in thedialog's event handlers, 'cause they get called in context of the mainthread with the lock already acquired.Since Nautilus, as I pointed out, also doesn't seem to suffer fromthis inter-thread GUI problem, I am sure I am missing something. Ithought maybe someone here knows since I was pretty sure that theNautilus developers read this list.Nau is open source, isn't it? You could take a look at the sources andfind out everything you need to know ;)If you show a part of the code you're talking about, probably you get amore helpful advice on it.wbr, Dmitry.

_______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

#5 Oct. 28, 2005 10:20:01

Matthias K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


For a better understanding of my problem, please have a look at thisfunction, which is called from a thread running parallel to the threadowning the Gtk lock:(Please notice the comments!!)

/// Handles a file overwrite request encountered during a transfer.
int TransferDirector::handle_status_overwrite(
const Gnome::Vfs::Transfer::ProgressInfo& info)
{
using namespace Gnome::Vfs;

// hide the transfer dialog
// Please note that NO calls to gdk_threads_* are needed!!
// I have NO idea why; it just works
dialog_->hide();

// create the message dialog
TransferOverwriteDialog dlg(
get_local_path_from_uri(info.get_target_name()));

// Please note that here the two calls ARE NEEDED!
// If I leave them out, the program will lock up
gdk_threads_enter();
int response = dlg.run();
gdk_threads_leave();

OverwriteAction action;

switch (response)
{
case TransferOverwriteDialog::RESPONSE_REPLACE:
action = dlg.is_remember_choice()
? XFER_OVERWRITE_ACTION_REPLACE_ALL
: XFER_OVERWRITE_ACTION_REPLACE;
break;
case TransferOverwriteDialog::RESPONSE_SKIP:
action = dlg.is_remember_choice()
? XFER_OVERWRITE_ACTION_SKIP_ALL
: XFER_OVERWRITE_ACTION_SKIP;
if (info.get_total_files() == 1)
completion_scheduled_ = true;
break;
case TransferOverwriteDialog::RESPONSE_CANCEL:
action = XFER_OVERWRITE_ACTION_ABORT;
if (info.get_total_files() == 1)
completion_scheduled_ = true;
else
cancellation_scheduled_ = true;
break;
default:
assert(false);
}

// show the transfer dialog again
// AGAIN, the two calls are NOT needed!
dialog_->show();

return action;
}I think this function pretty much shows why I think I do not know thewhole story; it just doesn't make any sense to me that I need to lockGtk for the one dialog, but not for the other.The only differences between the two dialogs are that one is non-modaland has been created (but not displayed!) in the main thread, while theother one is modal and has been created in place (see code).Sorry, but I'm really lost here, any clarification on the behavior ofGtk+ in these situations much appreciated.Regards,
Matthias

_______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

#6 Oct. 28, 2005 10:22:30

Matthias K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


Dmitry Konyshev wrote:When the lockup actually happens? You mustn't use the lock in thedialog's event handlers, 'cause they get called in context of the mainthread with the lock already acquired.No, it's happening in a gnome-vfs signal handler. No Gtk lock isacquired there.Nau is open source, isn't it? You could take a look at the sources andfind out everything you need to know ;)If you show a part of the code you're talking about, probably you get amore helpful advice on it.As I said, I have read the source code in question, as well as the eelsources of the dialog functions which are used and I couldn't findanything related to locking or unlocking. Here are the relevant parts ofthe Nautilus source which involve showing a message dialog in a signalhandler which is called from the async transfer functions running in aseparate thread:handle_transfer_overwrite (const GnomeVFSXferProgressInfo *progress_info,
TransferInfo *transfer_info)
{
int result;
char *text, *primary_text, *secondary_text, *formatted_name;
gboolean is_merge, target_is_dir;nautilus_file_operations_progress_pause_timeout(transfer_info->progress_dialog);... snipped handling of some special cases here

/* transfer conflict, prompt the user to replace or skip */
formatted_name = format_and_ellipsize_uri_for_dialog (
parent_for_error_dialog (transfer_info),
progress_info->target_name);


... snipped some text formatting here


if (progress_info->duplicate_count == 1) {
/* we are going to only get one duplicate alert, don't offer
* Replace All
*/
result = eel_run_simple_dialog
(parent_for_error_dialog (transfer_info),
TRUE,
GTK_MESSAGE_QUESTION,
text,
secondary_text,
_("Conflict While Copying"),
_("_Skip"), _("_Replace"), NULL);
g_free (text);nautilus_file_operations_progress_resume_timeout(transfer_info->progress_dialog);switch (result) {
case 0:
return GNOME_VFS_XFER_OVERWRITE_ACTION_SKIP;
default:
g_assert_not_reached ();
/* fall through */
case 1:
return GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE;
}
} else {
result = eel_run_simple_dialog(parent_for_error_dialog (transfer_info), TRUE, GTK_MESSAGE_QUESTION,text,secondary_text,
_("Conflict While Copying"),
_("Replace _All"), _("_Skip"), _("_Replace"), NULL);
g_free (text);nautilus_file_operations_progress_resume_timeout(transfer_info->progress_dialog);switch (result) {
case 0:
return GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE_ALL;
case 1:
return GNOME_VFS_XFER_OVERWRITE_ACTION_SKIP;
default:
g_assert_not_reached ();
/* fall through */
case 2:
return GNOME_VFS_XFER_OVERWRITE_ACTION_REPLACE;
}
}
}As you can see, no gdk_threads_enter() or gdk_threads_leave(). I alsoread the source code of eel_run_simple_dialog() but it doesn't involvedispatching signals to the main thread or anything else related tothreading.Regards,
Matthias
_______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

#7 Oct. 28, 2005 13:00:03

Dmitry K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


Matthias Kaeppler wrote:I think this function pretty much shows why I think I do not know thewhole story; it just doesn't make any sense to me that I need to lockGtk for the one dialog, but not for the other.The only differences between the two dialogs are that one is non-modaland has been created (but not displayed!) in the main thread, whilethe other one is modal and has been created in place (see code).Sorry, but I'm really lost here, any clarification on the behavior ofGtk+ in these situations much appreciated.gnome-vfs seems to send its notifications in context of the main thread.I don't know how it happens that your function gets called from anotherthread.wbr, Dmitry.


_______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

#8 Oct. 28, 2005 13:21:01

Matthias K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


Dmitry Konyshev wrote:gnome-vfs seems to send its notifications in context of the main thread.I don't know. Does it? It almost seems so when looking at the Nautilussource, but I haven't read anything about that in the documentation.Afterall, its purpose is to allow for transfers running asynchronouslyto the main thread, so why should it call its signal handlers fromanywhere but its own thread of execution?I don't know how it happens that your function gets called from anotherthread.I thought this is how gnome-vfs' async functions work. You connect yoursignal handlers, start the transfer(), it kicks off its own thread andsends updates periodically to report progress. In this case I see noreason why my signal handler would not be called from the thread whichis running the transfer (and which is most certainly not the main thread).- Matthias

_______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

#9 Oct. 28, 2005 13:37:02

Dmitry K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


Matthias Kaeppler wrote:Dmitry Konyshev wrote:gnome-vfs seems to send its notifications in context of the main thread.I don't know. Does it? It almost seems so when looking at the Nautilussource, but I haven't read anything about that in the documentation.Afterall, its purpose is to allow for transfers running asynchronouslyto the main thread, so why should it call its signal handlers fromanywhere but its own thread of execution?gnome-vfs sources, file gnome-vfs-job.c, function job_notify. It addsidle handler, that calls the callback, to the main loop. It doesn't callthe callback function by itself in its own thread.I don't know how it happens that your function gets called fromanother thread.I thought this is how gnome-vfs' async functions work. You connectyour signal handlers, start the transfer(), it kicks off its ownthread and sends updates periodically to report progress. In this caseI see no reason why my signal handler would not be called from thethread which is running the transfer (and which is most certainly notthe main thread).You can use gdb to set up a break point in your function and see howexecution flow gets to your function and in which thread's context.wbr, Dmitry.

_______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

#10 Oct. 28, 2005 16:19:27

Matthias K.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

Opening dialogs outside the Gtk thread?


Dmitry Konyshev wrote:gnome-vfs sources, file gnome-vfs-job.c, function job_notify. It addsidle handler, that calls the callback, to the main loop. It doesn't callthe callback function by itself in its own thread.That's good to know of course, thanks.In other words, the crash occuring in my program may not be related atall to a synchronization error? That's really odd, because the problemgoes away after locking the gdk mutex.Heh, now I'm even more confused than before, since the error in factshouldn't even occur! *sigh* I'll try to check with gdb from whichthread it's called. Maybe it's an error in the C++ bindings tognome-vfs, and not in my code._______________________________________________
gtk-list mailing list
gtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list

Offline

  • Root
  • » GTK+
  • » Opening dialogs outside the Gtk thread? [RSS Feed]

Board footer

Moderator control

Enjoy the 18th of November
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support