GNOME Bugzilla – Bug 124902
HIG doesn't specify Esc key usage
Last modified: 2020-12-04 18:20:48 UTC
AFAIK, the HIG doesn't specify Esc key default behaviour (or whatsitcalled). Anyway, what I mean is when I take these steps: 1. Open gEdit, press Ctrl + F (find); 2. Close (cancel) the Find window again by pressing Esc. step 2 doesn't work; instead I'll have to find the right Alt shortcut key for the button. The pros for using Esc instead would be: - De facto standard: Windows users use it all the time. Programs like Mozilla implement this behaviour too; in fact, many GNOME apps do so too. (I.e.: Evolution: Ctrl + N, Esc even lets you create and cancel a whole new message, confirming changes if needed). I don't know how Mac apps use Esc, though. - It is faster than using the Alt key combination, and people can get far with the keyboard, knowing only a few shortcuts and Enter and Esc. Also, common behaviour is better; now only half the apps use it, as there's no policy. - The Esc button is rarely hit accidentally, so it's not like there's a big risk involved. If, for whatever reason, you'd be against this Esc key assignment, I think this would also be worth mentioning in the HIG, with reasons why NOT to use it. Anyway, thanks for your time!
Oh BTW, IMHO, these are the actual options for assigning Esc: 1. On Cancel/ OK, assign resp. Esc/ Enter 2. On OK (a confirmation message with no choice), assign both to OK 3. On Close (direct update configuration dialogs), assign Esc only Currently, only Enter is assigned by the HIG. Option nr. 1 is the most important; nr. 2 is discutable (maybe you want that message to be read before it's Esc'd away), and nr. 3 is mainly a matter of taste. (Currently, Enter is not assigned to Close in fear of accidentally pressing it. Is Esc both safe and intuitive to use here?)
There is policy, it's just not been made clear in the HIG. Escape cancels a mode or stops an operation in progress, and nothing else. Here the GNOME guidelines are like those for Windows and the Mac. All fail to mention that Escape is _only_ Cancel or Stop. The combination Alt+F4 should do the same as pressing the window frame close button in all GNOME-compliant window managers. There's no need to seek out the access key. Ideally Ctrl+W would also work the same way, but that won't happen any time soon. The main problem is not speed or risk, it's consistency. When a modal dialog closes, it does either something (OK) or nothing (Cancel). When a modeless dialog closes, it always just closes. Imagine explaining the difference to a user. Because modeless dialogs and utilities will often have "micro-modes", there is a risk of pressing Escape accidentally. By micro-mode, I mean for example editing mode in a list: Escape cancels the edit, and everything else (iirc) accepts it. Amusingly enough the one control panel that most invites this error is the one that allows it; keybindings. Almost every request I've seen for Escape to close modeless dialogs is a complaint about Find in some app. There is a problem here, and it's the design of the feature in those applications. Find probably shouldn't be a modeless dialog at all; it should be a utility window, if it's to be a modeless secondary. It could also be a modal dialog. A micro-mode, like incremental search in emacs, is probably the best solution. (Standard Rants: Non-frame close buttons are wrong, modal dialog is redundant, modeless dialog is nonsense, etc.)
See #101293 for the corresponding bug in GTK+. This should not be GTK+ policy, e.g. it should not have code like esc_key_pressed_callback () { if (!dialog_has_cancel_button ()) return; /* Do nothing */ else close_dialog (); } This should be application-side policy. See the "Default button" section here: http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGDialogs/chapter_17_section_3.html And read what it says about the Escape key.
Also see http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGDialogs/chapter_17_section_3.html and look for the "Escape" section.
As far as I can see, all the Default Button section says is "always bind Esc to Cancel", and the Shortcut Keys chapter (http://developer.apple.com/documentation/UserExperience/Conceptual/OSXHIGuidelines/XHIGUserInput/chapter_10_section_3.html#//apple_ref/doc/uid/TP30000361/CHDIGFBH) says that Esc is reserved by the system to mean "cancel the current action", and specifically that: "The user can press Escape in the following situations: * In a dialog, instead of clicking Cancel (note: no mention of using instead of clicking close) * To stop an operation in progress (such as printing), instead of pressing Command-period * To cancel renaming a file or an item in a list * To cancel a drag in progress" All of this seems to be in agreement with the current HIG guidelines/gtk+ behaviour...?
Actually, the Apple guidelines suggest always including a Cancel button, bound to Escape, and that the meaning is "forget I mentioned it". In other words, if you go into Find, press next until you find the hit you want, and then hit Esc/Cancel, it should actually revert the scroll state of the window back to where you were before the find started. This is clearly not what we want!
Anyway, Apple aside... I agree with Calum and Bryan that find dialogs are the only place where there seems to be an issue (because that is where people are used to doing keynav). ALT-F4 is considered an acceptable shortcut for close window, so why isn't ALT-F4 (or ALT-C if you prefer) acceptable for getting rid of the find dialog? So the issue at hand is one of "I'm used to this, not that". That's not to say its not a valid issue, but I think its important to recognize. Like Gregory I am (and was) generally opposed to the idea of Close buttons in the first place. I think this issue would be much clearer if Close was really understood to mean "close window" not "something similar to cancel". Now I would not be entirely opposed to mapping ESC to "Close Window" (along with ALT-F4)... but this might raise a new set of issue because then we have no mapping for Cancel. I have noticed that many dialogs with Cancel buttons also have Close in the window titlebar, and that this does the same thing as Cancel. Does every dialog that has a Cancel button also have a Close button in the window title? In that case we have already conflated Cancel and Close, and I suppose it would be reasonable for ESC to generally map to "get rid of this window". The meaning of "get rid of this window" would then vary depending on whether "this window" was a dialog or another kind of window, but we already have that confusion (e.g. with ALT-F4).
Please see this: http://developer.gnome.org/projects/gap/testing/keynav-test-cases.html The Key_004 test says: "Pressing Esc should close a secondary window that has Cancel or Close buttons, or in menus or other popup windows that have no explicit close controls to click on." What gives?
An error on Wipro's part, I would suggest :)
Damn, I thought that was my ace under the sleeve.
The idea of using Alt-F4 to close a Find dialog scares the hell out of me. I pray to God I'll never have to use it except to close main application windows. Alt-C is troublesome for those with more than one keyboard layout. I may edit Russian text in Engish-language Gnome, others may edit English text in a Russian Gnome. In either case you'll have to 1) switch layout 2) Press Alt-Shortcut key 3) switch layout back. Just to close a Find dialog? Ridiculous. HIG doesn't specify a convenient "Close this dialog" shortcut that works always and everywhere. It is what Esc does in Windows and it is what many people switching from Windows are missing in Gnome.
*** Bug 168599 has been marked as a duplicate of this bug. ***
*** Bug 148832 has been marked as a duplicate of this bug. ***
I think we currently use escape quite consistently, so I've added a few notes on it: https://git.gnome.org/browse/gnome-devel-docs/commit/?id=f6e60f87203ad4e74fe1da262735aa8e3c375fd0 The only controversial part of this, I think, is recommending Escape for Close as well as Cancel (which is essentially what happens currently, I might add). There probably needs to be some detail provided here, but I think it's enough to close the bug.