GNOME Bugzilla – Bug 78999
Use common keybindings.
Last modified: 2004-12-22 21:47:04 UTC
Windows, CDE, and OS/2 all pretty much adhere to the CUA standard for window keybindings. That can be seen here and in related topics: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F29AL000/2.2.117?SHELF=CEESL002&DT=19921204095534 Many Windows help and hints sites on the web suggest using the mnemonics in the system menu for keyboard control of windows and explicitly identify at least some of them. At least in Win98SE, Microsoft does not use the Alt+Fn shortcuts except Alt+F4 for Close, so most Windows users are apt to expect the mnemonics to work. Here is a partial reference, with mnemonics indicated in GtkLabel style: _Restore Alt+F5 _Move Alt+F7 _Size Alt+F8 Mi_nimize Alt+F9 Ma_ximize Alt+F10 _Hide Alt+F11 (OS/2 3.0) _Lower Alt+F3 (Motif) --------------------- _Close Alt+F4 --------------------- Window list Ctrl+Esc (system menu item on OS/2 3.0; opens Start menu on Win98SE) And, of course, Alt+Space opens the system menu on all of these. Boring details, to explicate hiding and the window list: On OS/2 3.0, Hide and Minimize are exclusive. Objects such as the window list which would be silly to minimize (into the Minimized Window Viewer, or onto the desktop) have Hide. Hidden windows appear only in the window list. There is no "taskbar". For most objects, the behavior is configurable; for those that are, the setting is made by selecting one of the three radio buttons: Hide, Minimize window to viewer, or Minimize window to desktop. That radio group is only sensitive if the window has a minimize button instead of a hide button; which button is also configurable. The window list is actually a list, not a menu. This allows selecting multiple windows for operations such as tile and cascade. All actions close the list. The list does not include itself.
Suggest this needs to be upgraded to major/high, at least until the metacity window menu has ATK bindings that would allow it to work with a screenreader etc.(which may not happen as soon as we'd like). Without that, and these default keybindings, there is no easy way for a blind user to perform the standard window operations.
Does anyone know why Windows doesn't have these default bindings? I would like to understand their rationale if possible.
Hmm, I have no idea actually, Windoze doesn't use those keys for anything else either AFAIK... although some Office apps do use them for their own purposes and probably have done for years, so maybe they didn't want to upset their Office users :) CDE, OS/2 and other CUA-compliant desktops certainly do use these keybindings, though.
Havoc, have you had any more thoughts on this? We need to decide Real Soon Now whether to provide these keybindings in a Sun patch or not.
Surely Windows has default bindings here - what are they? (I'd perhaps rather be consistent with Windows than CUA, if we're going to be consistent with something, just based on sheer number of people used to Windows keybindings vs. OS/2 or CDE.)
I don't know why I'm even bothering with this, but I stated in the original report what parts of the CUA have been retained by Windows; all you have to do is scroll up and read. Since elsewhere so many people have indicated an inability to do this, here's what Windows has. _Restore _Move _Size Mi_nimize Ma_ximize ---------------- _Close Alt+F4 And Alt+Space opens the menu. That's Windows, as I already said. Not mentioned before: When the command could never apply, it isn't on the menu. (e.g., a Windows dialog would not be restorable, resizable, minimizable, or maximizable.) When the command could apply but it isn't applicable at the moment, it is present but insensitive. All of the CUA-derived systems (Windows is one of them) will place other commands on the system menu; however, except on OS/2, there is rarely a discernable scheme. Browsing the web seems to be a missing skill to, but hopefully going to a URL isn't: http://msdn.microsoft.com/library/en-us/dnacc/html/ATG_KeyboardShortcuts.asp?frame=true Of course, given the scrolling problem, that won't be to useful as the relevant part is near the bottom of the page; but maybe people know how to scroll down, just not back up. Furthermore, at least one Sun beta tester has already indicated that not being able to lower a window is a problem. Lastly, those obsessed with Windows should seek psychiatric help.
Gregory, please don't help any more with any of my software. I don't need it. Thanks.
Apart from the question who's helping who and why, let me just add that IceWM offers the mentioned keybindings, and I would very much appreceate these being available in metacity. FWIW.
Created attachment 10376 [details] [review] patch: fixes the problem
The above patch: 1) Adds keybindings 2) Changes some of the mnemonics 3) Reorders some the menu items Below the order & mnemonics are given. Beside it i have mentioned the associated keybindings. _Move Alt+F7 _Resize Alt+F8 Mi_nimize Alt+F9 Ma_ximize Alt+F10 _Shade [there is no keybinding associated with this] ---Seperator----- _Close Alt+F4 ---Seperator----- ..... When the window is maximized then the option _Unmaximize appears on top of all the items. i.e. before _Move option. Is this patch ok ?
If the Close menu item is moved down then that would be of influence on bug 83892 (see the comment of Isaiah Weiner).
I reordered some menu items earlier today, and just added some default keybindings. Remaining stuff: - I didn't put move/resize at the top of the menu since I doubt anyone uses a mouse for these, and with mnemonics it doesn't matter that they are convenient at the top - didn't change mnemonics since I'm in a mini-string-freeze for a week or two - need to add a "maximize" and "unmaximize" keybinding setting, instead of just "toggle_maximized", in order to get the bindings for maximize/restore right.
This is great... however, it's kind of undiscoverable at the moment because (unless my build is broken) the shortcuts don't appear on the menu in the way that shortcuts normally would. How hard would it be to add this? Also, any timescale on when you'll be doing adding the maximize/restore settings? We need to work out in the next day or two whether to try and produce a local patch for this, as it's a Sun requirement.
> the shortcuts don't appear on the > menu in the way that shortcuts normally would. How hard would it be > to add this? I'm not sure. It might be easy. I just haven't looked. You can't do it the normal GTK way as the accelerators aren't accelerators in the normal GTK sense. I'm not sure if GtkAccelLabel does what we want or not. > Also, any timescale on when you'll be doing adding the > maximize/restore settings? It is about a 15 minute task. Just everywhere you see toggle_maximize add equivalent stuff for maximize/unmaximize. I will try to remember soon, anyone else can feel free to attach a patch...
Created attachment 10591 [details] [review] patch for adding maximize and unmaximize keybinding settings
Created attachment 10592 [details] [review] patch for adding the bindings in gnome-control-center
havoc: is the patch for un/maximize bindings ok to commit ?
Yes, this patch looks good, thank you. Please commit.
Committed the patch.
I created a separate bug (#91336) for the 'shortcuts not appearing on menu' bug, so we can close this one when the mnemonics are changed over to the suggested ones (which probably isn't a terribly high priority)...
2002-09-24 Havoc Pennington <hp@redhat.com> * src/menu.c: change mnemonics to match bug #78999
are all the changes made as described in the original report above? did they only go back on 24th sept? cheers shane