GNOME Bugzilla – Bug 109194
Can't close dialogs by keyboard sensible/consistently
Last modified: 2020-12-04 18:19:49 UTC
A lot of dialogs and similar windows can't be closed by the keyboard in a sensible way. Some examples: the find-dialog in galeon2: Has a Close-Button, but the shortcut Alt-C is language dependant and not consitant. the properties of a galeon2 bookmark: No Close-Button whatsoever and no way to close it but to use the window managers controls. the message dialog of gnomeicu: Has a Close-Button which can be accessed by Alt-C, but since there is also a Chronic, Alt-C does not immidiately close the window. (Ok, this was fixed a couple of days ago, but might be the case elsewhere or happen again). I propose: Either to allow the ESCAPE key to close these kind of windows (basically any window that has a Close or Cancel window, but has no Alt-W which should be used for "main" windows if I got it right), or define a consistent and fast key (since closing these dialogs is very important and very frequent) for it. (but no idea what key that could be)
note, any window can be close using the window manager close keybinding (typically alt+f4) > the properties of a galeon2 bookmark: No Close-Button whatsoever and > no way to close it but to use the window managers controls. Well according to the gnome hig this would be a bug (of course I don't think that any dialog should have a close button besides the window border one, but thats not gnome's current policy) As for using escape, I'll leave that up to calum to comment on, he may have some good arguments for/against.
I disagree that we should rely on the window manager. Some people might want to use a weird theme or a window manager like ratpoison. I'd rather have a standard "Close" button with ESC or another "fast" key to close.
Is this part of the freedesktop WM specification? It's perfectly OK for GNOME to demand a freedesktop-compliant WM. I reaally don't think we need to duplicate all WM features in the apps.
I would consider both the issues in the original report to be bugs against those applications. The current HIG recommendation, in a nutshell, is that a window should always have either a Close/OK-type button, *or* a File->Close/Quit menu item. (Some people don't like this, but that's the way it is today). And controls with mnemonics that clash with any standard dialog buttons in the same window (OK/Close/Cancel/Help) should be avoided pretty much at all costs, although the HIG doesn't explicitly say so at the moment. As for the Escape key, it's currently meant to be used exclusively to mean "Cancel", so IMHO it would be confusing if it was used to mean "Close" in some places as well.
Have just updated the draft HIG to explcitily say that controls with mnemonics that clash with any standard dialog buttons in the same window (OK/Close/Cancel/Help) should always be avoided. in light of that, will be marking this as WONTFIX soon unless somebody can persuade me that you can't close any window in any HIG-compliant application with a single, non-window manager shortcut...
no one has complained, marking wontfix.
I'd like to complain. I understand that you made "the draft HIG to explcitily say that controls with mnemonics that clash with any standard dialog buttons in the same window (OK/Close/Cancel/Help) should always be avoided." But now Epiphany doesn't close the Find dialog box with ESC. Sure, I can use ALT-C or ALT-F4 .. but those are slightly more difficult key combinations, and this breaks the standard behavior that everyone else is used to in all other browsers. I hit escape, and my computer sits unresponsive and unknowing what to do. I understand what you have written the HIG to say ... but here is a perfectly good key on the keyboard that would be letting the application act as expected and cause zero problems.
Complaint noted, but I suspect the real solution here is probably to fix bugs #85606 and #101293 (which effectively amounts to "doing Find dialogs differently"), since people only ever really seem to file bugs about this behaviour in relation to Find dialogs.