GNOME Bugzilla – Bug 99529
Sync human readable accel string format between menus and capplet
Last modified: 2007-07-29 20:06:52 UTC
o Keyboard Shortcuts - Treeview needs stripey lines - Emacs/GNOME shouldn't really exist in the UI -- leave Emacs option behind some GConf/rc key - s/Display "Run" dialog/Display "Run Application" dialog - s/shortcut/shortcut key/ - Metacity keybindings should use 'Desktop Background' to be consistant with the other documentation - s/screen shot/screenshot - 'Raise window if obscured, lowers it otherwise' -- s/lowers/lower/ #imperative - 'Toggle whether the window is on all workspaces' -- s/the/a/ #or should the others be change to "the window" instead? - <Gnils> i'll tell you one thing, its real easy to screw up shit, and have no idea what the default was - <huey> Would it perhaps be better to have the categories (Desktop, Window Management) in a combobox? That means less scrolling.
*** Bug 98039 has been marked as a duplicate of this bug. ***
*** Bug 98040 has been marked as a duplicate of this bug. ***
- From bug 98040: Shortcuts should be displayed as "Alt + F1" instead of "<Alt>F1" for consistency with docs
Created attachment 27522 [details] [review] Proposed patch I filed bug 142235 for Metacity specific stuff. This patch fixes most of the concerns raised. It does not deal with splitting shortcuts into categories or having a 'go back to defaults' button. I also changed some shortcuts that were using header capitalization to use sentence capitalization. I removed the option box for the keyboard theme. Without it, I felt there was no need for the shortcut label, so I took it out too. The code to switch <Alt>F1 to Alt + F1 could use a review, particularly if there is an easier way to do it. Should I submit that change to libegg HEAD?
Adding PATCH keyword.
Comment on attachment 27522 [details] [review] Proposed patch The <Alt> + foo syntax is a problem begging to happen. <Ctrl> + <Shift> + + is going to look really odd to a user and I don't even want to consider what will happen with keys that don't have keysyms I'm also somewhat leary of tossing the gnome/emacs switch. Can the usability folk provide a bit more justification for that ?
> I don't even want to consider what will happen with keys that don't have keysyms What happens on gtk menus, if you dynamically reassign a menu shortcut to the same combo? Really the main aim of this request (IIRC, it was a long time ago now) was to ensure consistency of shortcut nomenclature across the desktop and documentation-- if there are shortcuts it doesn't work for, then it probably needs solving everywhere, not just here. > I'm also somewhat leary of tossing > the gnome/emacs switch. Can the usability folk provide a bit more justification for that ? Again, it's been a long time, but I suspect the feeling was that it was one of those funky settings that most users would never touch with a bargepole, which we've been trying to eradicate from preferences dialogs. (Using the term "most" advisedly here, since I personally have no clue how many people really change it.)
Comment on attachment 27522 [details] [review] Proposed patch After smoe consideration I'll put in the string changes, and the removal of the emacs vs gnome keybinding theme selector. I'm even mostly convinced that the concept of the change to the accel display format is useful if we can jazz it up a bit by bolding the key eg <Ctrl> + <b>+</b> However, the submitted patch to parse the resulting accel name and reformat it is a kludge.on a few levels. I'm not convinced that we will never see a keysym '<' or '>'. I'll commit the other parts.
any news on this ? The theme selector is out of the UI now but have you commited/planned to commit the other changes soon ?
Jody? Please reply.
We are now using the GTK+ accel format for displaying the accels. I guess that means the last (?) open point here is now fixed?
No objections until now. Assuming fixed.