Re: Opening dialogs outside the Gtk thread?
- From: Matthias Kaeppler <matthias finitestate org>
- To: Dmitry Konyshev <moodmonger bk ru>
- Cc: gtk-list gnome org
- Subject: Re: Opening dialogs outside the Gtk thread?
- Date: Fri, 28 Oct 2005 11:19:12 +0200
Dmitry Konyshev wrote:
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.
No, it's happening in a gnome-vfs signal handler. No Gtk lock is
acquired there.
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.
As I said, I have read the source code in question, as well as the eel
sources of the dialog functions which are used and I couldn't find
anything related to locking or unlocking. Here are the relevant parts of
the Nautilus source which involve showing a message dialog in a signal
handler which is called from the async transfer functions running in a
separate 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 also
read the source code of eel_run_simple_dialog() but it doesn't involve
dispatching signals to the main thread or anything else related to
threading.
Regards,
Matthias
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]