GNOME Bugzilla – Bug 101293
Rationalize GtkDialog close/cancel keybindings
Last modified: 2011-08-18 16:30:37 UTC
This bug is inspired by bug #74221 Right now we have a "close" keybinding signal which in fact only works if the dialog has a cancel button, and sends a delete_event. But delete_event itself can still occur if you don't have a cancel button. Opinion on more rational setup: - we have a "cancel" keybinding signal that sends GTK_RESPONSE_CANCEL iff you have a cancel button, and is bound to Escape by default - we have a "close" keybinding signal with no binding by default that sends delete event (and always works even without a cancel button)
What is the authority for the decree that Esc is not allowed to invoke close? Google turned up, http://developer.gnome.org/projects/gap/keynav/gtk_buttons.html, Keyboard Navigation for GNOME 2.0 (Draft). Was there ever a decision? Mede by whom?
The fact that ESC doesn't close the GEdit find box is driving me mad. I don't really know where to register that complaint (there is no bugzilla product for keybindings), so cc'ing Calum here.
Ping. We have the same problem in Evolution; I submitted a few patches to manually add an Esc accelerator to the Close button of several "Find"-type dialogs, but it is a pain.
The original rationale for this was fairly straightforward: Cancel and Close usually mean the exact oppposite of each other (Cancel = "forget everything I just did and close the window", Close = "remember everything I just did and close the window"), so assigning the same shortcut to both of them seems flawed on the face of it. (Could be even worse if you're blind). As you know, Owen even committed a gtk patch to follow this rule. AFAIR, people have only ever really filed bugs about it against "Find-type" dialogs, and almost exclusively against gedit (#101293, #102282, #115070, #118511), so personally I'm more inclined to think there's something wrong with the way we design Find dialogs :) Either way it sounds like we might need to do something about it, I'm just not sure what right at the moment... there are already four ways to Close a window (alt-c, alt-f4, click the X button, click the Close button itself), do we really need a fifth...?
There was a thread about closing dialogs with Esc on gtk-devel-list: http://mail.gnome.org/archives/gtk-devel-list/2003-December/msg00065.html Gregory Merchan favours the status quo, whereas Federico Mena Quintero, Jody Goldberg and Joaquin Cuenca Abela want Esc to close dialogs. So do I.
<Calum> AFAIR, people have only ever really filed bugs about it against "Find-type" dialogs, and almost exclusively against gedit (#101293, #102282, #115070, #118511), so personally I'm more inclined to think there's something wrong with the way we design Find dialogs </Calum> I can tell you why this is. People hit Control-F to find when they are using the keyboard - either to type text (gedit), or to scroll up and down through webpages (ephy). So they try to cancel it with ESC. In a preference window there are oodles of widgets, so people who can tend to use the mouse, so there are no bugs filed about it behaving unexpectedly with the keyboard. But I agree with a lot of people that not being able to get rid of a dialog with ESC feels weird.
<Andrew> People hit Control-F to find when they are using the keyboard - either to type text (gedit), or to scroll up and down through webpages (ephy). So they try to cancel it with ESC. In a preference window there are oodles of widgets, so people who can tend to use the mouse, so there are no bugs filed about it behaving unexpectedly with the keyboard. </Andrew> Hey Andrew, I'm glad you added this because as usual I'm going to agree with Calum that our Find dialogs are incorrectly structured and that the ESC binding does not need to be changed. I'm going to note this particluar sentance: "So they try to cancel it with ESC." Now if Find dialogs used a 'Cancel' button instead of the 'Close' button they would inherently gain the ESC key binding, plus I believe they would be more intuitive to what is really happening. The user presses Ctrl-F to start a find and then presses ESC to cancel the find. 'Close' doesn't enter the metaphor at all since the find doesn't need to be closed, but canceled. It's a subtle difference, but one that I think is worth noting. There are also some more improvements that could be done, but this is one step in the right direction. I'm going to move that the patches on these find dialogs change the close button to a cancel, instead of adding new key bindings to the close button.
Fixed in HEAD as discussed on the list. Esc is bound to the "close" signal, whose default handler just synthesizes a delete_event on the dialog.
Reopening due to lack of consensus.
It seems to me that "Close" is the right word, since Cancelling the find would imply that the find is undone, but in practice no one wants that (ie Escape would move back to the original location of the cursor/viewport).
Actually Close and Cancel are both off the mark for terminology here. What does "Cancel Find" mean? Cancel was an attempt to feed into the users model of a dialog, however we use Cancel to describe the action of not saving changes. Close is supposed to be similar to Cancel, except it will save changes on exit; this is why we use it for all the instant-apply preference windows. But what does "Close Find" really mean? I'd prefer something like the "Stop" button that was discussed in other bugs related to the Find dialog. http://bugzilla.gnome.org/show_bug.cgi?id=85606 "Stop Find", hopefully that conveys that the action will stop the current find in progress. Closing of the find window is an intuitive action related to the Stop of the find.
Attaching the patch that got reverted. I still think this is an application policy issue that does not belong in GTK+. The ChangeLog is this: 2003-12-15 Federico Mena Quintero <federico@ximian.com> * gtk/gtkdialog.c (dialog_has_cancel): Removed. (gtk_dialog_close): Don't call dialog_has_cancel(). At least allows sane behavior for #101293.
Created attachment 23327 [details] [review] Patch with proposed fix.
See bug #124902 for the currently incomplete HIG discussion.
No further action here, though it doesn't sound like the HIG people are budging, so maybe we should WONTFIX.
I'd hate to WONTFIX this. One of the first things novice users learn is that pressing the Esc key will always take them back to a safe state. Regardless of how friendly we make all dialog boxes, users will get scared by them and will want to go back to a safe state immediately. Even for experienced users, if you mistakenly hit a key combination that takes you to a dialog box, Esc is the natural response for "oops, I didn't mean to do that; now get out of my face". This should really be an application policy. Also, from the API point of view, it is really bad that using a custom response code for a cancel button will gratuitously make Esc not work.
*** Bug 136564 has been marked as a duplicate of this bug. ***
I think it's wrong for Esc to generate a 'close' signal. It should only close dialogs which don't have Cancel buttons (if at all).
to clarify, what I meant by "It should only close dialogs which don't have Cancel buttons (if at all)." was "ESC should invoke 'close' in dialogs without Cancel buttons, if at all; otherwise it should be bound to Cancel". This still feels somewhat busted though, because it means that ESC is bound to different things depending on the presence/absence of a Cancel button.
Federico wrote on the usability mailing list that he may commit a patch to GTK+ again to fix this issue. Go, Federico, Go!
I've reported a bug related to this at http://bugzilla.gnome.org/show_bug.cgi?id=331836 and would love to see Escape work in more dialogs.
*** Bug 331836 has been marked as a duplicate of this bug. ***
Fixed in HEAD.
I guess the discussion on usability mentioned in comment 20 is here: http://mail.gnome.org/archives/usability/2005-December/msg00032.html I cannot see any consensus there that this change should be done; so why are you forcing it on all of us then?
I'm forcing it because it is the right thing for you and your users. In every desktop platform *but* GNOME/GTK+, Esc means "get out of my face and return me to a safe state". We didn't support that at all in GTK+ 1.x; then we got it working right and in an elegant fashion with GTK+ 2.0, and then we broke it when someone started being foolishly consistent. Then people started complaining when dialog boxes didn't close with Esc. *No one* complained when they all closed with Esc.
> I cannot see any consensus there that this change should be done; so why are you forcing it on all of us then? Are you depending on Esc not working in certain dialogs?
> "In every desktop platform *but* GNOME/GTK+, Esc means "get out of my face and > return me to a safe state". Precisely why I've always argued against binding Esc to Close IMHO, because in instant-apply dialogs with a Close button, you've potentially already changed the state to something else which may or may not be "safe" (in that it's different from the state you were in when you started). Also worth re-iterating that both the Windows and OSX guidelines only /ever/ mention Esc as a shortcut for "Cancel", as far as I recall... I guess developers just saw the lack of an explicit "don't use it for Close" guideline as tacit permission to actually do so :) And frankly, I'm not going to argue about it any more, as it's clear that nobody else cares about the benefits of consistency in this case (except Bill and the a11y team).
> because in instant-apply dialogs with a Close button, What about doing revert instead of close in that case? > Also worth re-iterating that both the Windows and OSX guidelines only /ever/ mention Esc as a shortcut for "Cancel", as far as I recall... But about every Windows app (except those using alternative toolkits) closes a dialog when you hit Esc. Another way to look at this: what does the user expect to happen if he hits Esc? Is he happy when it's a no-op?
> What about doing revert instead of close in that case? A Revert function would indeed be valuable in many dialogs; the only reason we don't have any guidelines for such a thing now is that when we discussed it for the HIG, we all had different opinions on whether it should be Revert, or Undo, or Defaults, and ended up deciding nothing. I'm not sure that's relevant to this discussion though; Revert can be an equally valid function in both instant-apply and explicit-apply dialogs. > Another way to look at this: what does the user expect to happen if he hits > Esc? Is he happy when it's a no-op? If every app followed the guidelines, the user would know exactly what to expect. A Windows user may expect the dialog to close, but only because he's been used to a platform where some application developers have decided to invent their own guidelines, as they often like to do :) We have an opportunity to rectify that in GNOME, as we've done in other areas, to the advantage (in particular) of our users with accessibility requirements.
> If every app followed the guidelines, the user would know exactly what to expect. But what would he expect?
Just what the guidelines say :) Escape cancels if there's anything to cancel, otherwise it does nothing.
I doubt that's what normal users expect. It sure isn't what I expect. I think they'd consider that inconsistent behaviour too.
FWIW, I agreee with Calum that using ESC to cancel is a mistake. But of course, gtk+ keyboard navigation is completely and utterly inconsistent in many other respects. As an exercise, try explaining what "arrow down" does in a gtk+ application. Make sure you cover all cases.
err, I meant that it's a mistake to use ESC to *close*.
That's why when we wrote the 2.0 keynav spec, we deliberately avoided mentioning the arrow keys (at least as a means of moving between widgets)... they're undocumented in the user guide to this day. At the time we hoped their functionality would be disabled rather than remaining broken, but I guess that never happened...
*** Bug 119270 has been marked as a duplicate of this bug. ***
This change is against Aqua HIG (and apparently against GNOME HIG but I guess GNOME users know better whether to ignore that or not), and it's impossible to fix by unbinding the Escape key, because RESPONSE_CANCEL no longer works (and Escape of course must press Cancel button if it's there). I could make a patch which special-cases quartz backend (and win32 too, I guess), but it doesn't seem right. Could Escape key be unbroken instead please?
> This change is against Aqua HIG (and apparently against GNOME HIG but I guess GNOME users know better whether to ignore that or not) Can't the HIG be changed? I hate Escape being a no-op in certain dialogs.
Closing this old bug; the right behavior is in place since 2006.