summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorHiroyuki Ito <ZXB01226@nifty.com>2017-09-11 12:02:13 +0000
committerDaniel Boles <dboles@src.gnome.org>2017-09-12 20:52:43 +0100
commitefaf99b039f3882157df67f714dfa5a7af46f2a2 (patch)
tree0a13b11388e5d149127d86bcaac8473fc1ef83cb
parentc2739ba1e7c139dedd1b6d93d1e736799d8c305d (diff)
downloadgtk+-efaf99b039f3882157df67f714dfa5a7af46f2a2.tar.gz
ColorButton: Don’t destroy dialog @ ::delete-event
Without specifically connecting ::delete-event to something, the dialog will be destroyed when it is closed, for example by pressing Esc. This meant that when dismissing it this way, unlike by pressing Cancel, any custom palette would be lost when the dialog was next opened, and so on. Resolve this by making ::delete-event just do GTK_RESPONSE_CANCEL, so closing the dialog has the same effect as clicking its Cancel button. https://bugzilla.gnome.org/show_bug.cgi?id=787444
-rw-r--r--gtk/gtkcolorbutton.c12
1 files changed, 12 insertions, 0 deletions
diff --git a/gtk/gtkcolorbutton.c b/gtk/gtkcolorbutton.c
index b844d515fd..e583cda0dd 100644
--- a/gtk/gtkcolorbutton.c
+++ b/gtk/gtkcolorbutton.c
@@ -490,6 +490,16 @@ gtk_color_button_new_with_rgba (const GdkRGBA *rgba)
}
static gboolean
+dialog_delete_event (GtkWidget *dialog,
+ GdkEvent *event,
+ gpointer user_data)
+{
+ g_signal_emit_by_name (dialog, "response", GTK_RESPONSE_CANCEL);
+
+ return TRUE;
+}
+
+static gboolean
dialog_destroy (GtkWidget *widget,
gpointer data)
{
@@ -554,6 +564,8 @@ ensure_dialog (GtkColorButton *button)
G_CALLBACK (dialog_response), button);
g_signal_connect (dialog, "destroy",
G_CALLBACK (dialog_destroy), button);
+ g_signal_connect (dialog, "delete-event",
+ G_CALLBACK (dialog_delete_event), button);
}