After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 74221 - GtkDialog automatically emits the response GTK_RESPONSE_DELETE_EVENT when ESC is pressed
GtkDialog automatically emits the response GTK_RESPONSE_DELETE_EVENT when ESC...
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
2.1.x
Other Solaris
: Low trivial
: ---
Assigned To: gtk-bugs
gedit QA volunteers
Depends on:
Blocks:
 
 
Reported: 2002-03-11 09:53 UTC by keelin.boyle
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch for gtk+ that fixes this bug. (2.42 KB, patch)
2002-04-09 03:59 UTC, James Willcox
none Details | Review

Description keelin.boyle 2002-03-11 09:53:56 UTC
To Reproduce :

1) Start gedit2 &
2) Select Tools ->Plugins Manager & press Esc key.

Actual Result:
Close button is activated and Plugin Manager dialog is dismissed.

Expected result
 Esc should only operate Cancel buttons, not Close buttons.
Comment 1 Paolo Maggi 2002-03-11 10:03:47 UTC
Hmmm... 
so, in this case, if the user presses the ESC key, the dialog should
not dismiss itself. Right?
Comment 2 keelin.boyle 2002-03-11 10:24:33 UTC
Yeah, according to our keynev guidelines Esc should only activated
Cancel buttons (which it does), but not Close buttons.
Comment 3 Seth Nickell 2002-03-11 10:54:29 UTC
Yeah, I think I agree with this, but Calum would be the best person to
consult on keynav issues. My feeling is that "esc" very much connotes
some form of cancellation, and that we're better off having a consist
shortcut for "close".
Comment 4 Paolo Maggi 2002-03-11 11:13:05 UTC
Note that GtkDialog automatically emits the response
GTK_RESPONSE_DELETE_EVENT when you press ESC.
Comment 5 Luis Villa 2002-03-26 16:41:14 UTC
Paolo: so by your last comment, you're suggesting that this is a gtk
issue? Should we close this then, or refer the HIG people to gtk?
Comment 6 Paolo Maggi 2002-03-26 16:59:03 UTC
Here there are 2 problems: 
1. gedit problem: if the user presses the ESC key, the dialog should
not dismiss itself

2. gtk+ problem: GtkDialog automatically emits the response
GTK_RESPONSE_DELETE_EVENT when you press ESC. So I cannot know if the
user has pressed ESC or the WM close button.

To solve problem n.1 (in a general way) gtk+ guys should first solve
problem n. 2.

Comment 7 James Willcox 2002-04-09 03:56:31 UTC
I've attached a patch to gtk+ that fixes this by only closing the
dialog when the Esc key is pressed if there is a cancel button in the
dialog.  It still gives GTK_RESPONSE_DELETE (for compat. reasons). 
I've been unable to get an answer one way or another from gtk people
on whether this is ok, so I'm putting it here for now.
Comment 8 James Willcox 2002-04-09 03:59:54 UTC
Created attachment 7607 [details] [review]
Patch for gtk+ that fixes this bug.
Comment 9 venkat 2002-06-04 13:28:56 UTC
With the code  taken on 30th may, if the above steps are executed,
 tag list window is not getting closed.
Comment 10 Paolo Maggi 2002-06-04 15:26:44 UTC
venkat: please add your comment to the right bug report.
Comment 11 Paolo Maggi 2002-08-28 11:45:56 UTC
James: any news about your patch?

Owen: Do you think we should file a bug against gtk+?

Comment 12 Paolo Maggi 2002-11-23 10:04:42 UTC
James: could you please file a bug against gtk+ and put your patch there?

Comment 13 Paolo Maggi 2002-12-13 15:40:00 UTC
For more info read the thread at:
http://mail.gnome.org/archives/gtk-devel-list/2002-March/msg00563.html
Comment 14 Owen Taylor 2002-12-14 00:16:03 UTC
Fri Dec 13 18:57:20 2002  Owen Taylor  <otaylor@redhat.com>

        * gtk/gtkdialog.c: Change the Escape key binding to only close
        if the dialog contains a cancel button.  (Patch from
        James Willcox, #74221)
Comment 15 Havoc Pennington 2002-12-14 01:12:56 UTC
I would tend to make the Escape key send GTK_RESPONSE_CANCEL in this
case; I don't see how it would be incompatible to do so really.
Comment 16 Owen Taylor 2002-12-14 05:41:28 UTC
It seems very easy to me to have logic that depended on knowing
what the possible set of responses are. I can't think of
anything I've written that exactly would break here, but I've
certainly written gtk_dialog_run() calls that have some
expectation of what the result would be.
Comment 17 Havoc Pennington 2002-12-14 15:35:37 UTC
Sure, but GTK_RESPONSE_CANCEL is already known to be a possible
response in this case.
Comment 18 Owen Taylor 2002-12-14 16:09:26 UTC
Ah, you just mean change the current synthetic delete
event to a response signal.

It break a user who didn't listen to ::response, but
instead used the return from gtk_dialog_add_widget()
to g_signal_connect (..."clicked"). That probably doesn't
matter.

Be my guest if you want to fix it or open a new bug...

Comment 19 Havoc Pennington 2002-12-15 18:23:16 UTC
Looking at the code, it seems hard/impossible to make rational
in a simple way.

I filed http://bugzilla.gnome.org/show_bug.cgi?id=101293
to deal with it later.