GNOME Bugzilla – Bug 106991
add accelerators (mnemonic access keys) to all menus
Last modified: 2005-03-17 00:45:32 UTC
Currently the only way to bind a certain often-used function of GIMP is through keyboard shortcuts. However the set of shortcuts is rather limited and hard to come up with sensible (mnemonically correct and non-clashing) defaults. GIMP doesn't make much use of the so called accelerators[1]. It does use them on dialogs and even the toolbar menu has them for the topmost items. Most of GIMP's functionality is however in the image menu and we don't have any accelerators there. We can have a lot more functions being accessible fast without coming up with insane two-hand-a-foot shortcuts. These are sort of multidimensional. Imagine Alt,I,S for scaling image, Alt,S,S for shrinking selection etc. Being able to navigate menus with a keyboard fast is a high usability and workflow plus. Oh and if it wouldn't work in the default view, it should work in the new per-image-menubar, right? [1] The Gnome HIG has a short info about what to have in mind when setting up access keys - http://developer.gnome.org/projects/gup/hig/1.0/userinput.html#choosing-access-keys
First of all the menu itself needs to be made keyboard-accessible ...
Well, yes. I thought there was a bug report about that, but apparently this was only discussed on the developers mailing list two or three years ago and not reported here (or maybe I just couldn't find the right bug reports). Anyway, the first thing that we should do is to get rid of the last "Alt+key" shortcuts (such as Alt-R for RGB mode) and only use Ctrl for the pre-defined shortcuts. Then we can easily use Alt-F to pop up <Image>->File, Alt-E for <Image>->Edit, and so on.
GTK+ has a (user-configurable) shortcut to open menus which defaults to F10. As I just discovered, we already support this shortcut but the implementation is somewhat broken and needs fixing.
Mostly addressed by this commit: 2003-02-25 Sven Neumann <sven@gimp.org> * app/display/gimpdisplayshell-callbacks.[ch] * app/display/gimpdisplayshell.c: override GtkWidget::popup_menu() so we popup the Image menu on the default shortcut (Shift F10). * app/gui/image-menu.c (image_menu_entries): removed or replaced shortcuts that use the Alt key. Added access keys to all toplevel entries of the Image menu (see bug #106991). In my opinion this should be be sufficient. I don't think it makes sense to clutter the menus with more access keys. We do provide reasonable shortcuts to navigate the menus now. The individual menu entries can be easily accessed using the arrow keys. I vote for closing this report as FIXED.
I also vote for marking it FIXED. Jimmac, what do you think?
I would like to see all (or at least most) of gimp's features accessible with keys. I am now able to navigate there without using the mouse, yes (using cursor keys). But I'd prefer to memorize Shift+F10,i,i to indexing image, Shift+F10,e,v to copying visible selection etc... The current implementation stopped at the top level.
Basically it wouldn't be a problem to add more access keys. This does however collide with the ability to dynamically reassign shortcuts. If you ever hit the key at the wrong time, that is when a menu entry is focused which is not a sub-menu, you will assign the key to that entry (and remove the key binding from the menu it was bound to). I tried this feature and I ended up hating it. We can only do as Jimmac suggested if we disable dynamic key bindings and add a menu editor.
I'm not sure how much of a kludge it would be, but it may be useful to toggle the access keys off if gtk-can-change-accels = 1, avoiding the features clash? People preffering the access keys would get the functionality by setting this to 0. If this doesn't have some downside I can't imagine right now, we could discuss the possibility to have 0 be the default.
The downside is that you can't dynamically reassign keybindings if you turn this feature off. People seem to like it, that's why we turned it on. In my opinion we should only turn it off if we provide a good alternative, aka a menu editor.
FWIW, I do not like the dynamic assignment of shortcut keys because it is too easy to mess things up by typing the wrong key at the wrong time (especially if this steals a key that was assigned to something else and you do not remember where this something else was). So I would not miss this feature if it is disabled. But maybe there is a solution that would not require a complex menu editor: have the dynamic shortcut (re)definition turned off by default and add a toggle in the preferences box (or in any sensible place) that allows the user to enable that feature whenever needed. If GTK+ allows this to be changed at any time (I haven't checked yet), then we would have the best of both worlds: most users would have this off by default and would be able to use the keyboard shortcuts in all submenus. When they want to add or reassign some sortcut keys, they would enable the option, play with the menus, then disable the option again. Those who prefer the current way of assigning shortcuts at any time would simply keep this option on permanently.
I've checked GTK+ (and asked Owen) and it seems that we can easily change the value of "gtk-can-change-accels" on the fly. I'm starting to like the idea that Raphael suggested...
The CVS version now allows to enable/disable dynamic keybindings from the Preferences dialog. The default is to have it disabled.
Fixed in CVS: 2003-06-06 Michael Natterer <mitch@gimp.org> * app/widgets/gimpitemfactory.c (gimp_item_factory_set_label): use gtk_label_set_text_with_mnemonic() instead of just gtk_label_set_text(). * app/gui/image-menu.c * app/gui/toolbox-menu.c: added mnemonics for all sub-menus. Fixes bug #106991. * app/gui/image-menu.c: cleaned up the "Layers" menu: moved sub-menus together. Changed the "Stack" menu's labels and accelerators and added "Select Top/Bottom Layer" for consistency (bound to Home/End). * app/gui/layers-commands.[ch]: changed accordingly. Added the new select top/bottom callbacks.
Good stuff so far mitch ;) However there's a lot of items that don't have an accelerator. I discussed this with Sven on IRC. Here's why we want to try to have as many items with accelerator as possible: - there's not enough shortcuts (key combos) to cover one's need to access a function fast. Accelerators can solve this (just memorize alt+r,t,r for example) - navigating with cursor keys won't cut it (alt+f,r,up,up,up? what if an item is added? remember a new one? add a tear off - one more item in) Of course there's drawbacks. When adding a plugin a non-clashing accelerator needs to be figured-out. This is only per-menu-level, not global.
I don't know if this has any value to a gimp hacker ;), but most gnome2 apps make sure to have all (there's a few accel.-less, true) menu items accessible with an accelerator (nautilus, gedit, evolution ...).
Since we started the mission now, we must finish it or our menus will be inconsistent. Changed title and target milestone accordingly.
I have started work on adding mnemonics to the remaining menu items.
Created attachment 18831 [details] This is a list of mnemonics for <Image>/Filters. Some Script-Fus are registered there as well.
Added more mnemonics to CVS HEAD: 2003-08-01 Henrik Brix Andersen <brix@gimp.org> * plug-ins/rcm/rcm.c * plug-ins/print/print.c * plug-ins/pagecurl/pagecurl.c * plug-ins/mosaic/mosaic.c * plug-ins/MapObject/mapobject_main.c * plug-ins/Lighting/lighting_main.c * plug-ins/imagemap/imap_main.c * plug-ins/gimpressionist/gimp.c * plug-ins/gflare/gflare.c * plug-ins/common/mapcolor.c * app/gui/toolbox-menu.c: added more mnemonics to fix bug #106991. More will follow soon... I hope to be able to add mnemonics to the remaining entries after the weekend.
2003-08-04 Henrik Brix Andersen <brix@gimp.org> * plug-ins/pygimp/plug-ins/sphere.py * plug-ins/pygimp/plug-ins/pdbbrowse.py * plug-ins/pygimp/plug-ins/gimpcons.py * plug-ins/maze/maze.c * plug-ins/ifscompose/ifscompose.c * plug-ins/gfig/gfig.c * plug-ins/FractalExplorer/FractalExplorer.c * plug-ins/flame/flame.c * plug-ins/dbbrowser/dbbrowser.c * plug-ins/common/CML_explorer.c * app/gui/image-menu.c: added even more mnemonics to fix more of bug #106991. Still more to follow...
2003-08-05 Henrik Brix Andersen <brix@gimp.org> * plug-ins/common/align_layers.c * app/gui/image-menu.c * plug-ins/fp/fp.c * plug-ins/common/compose.c * plug-ins/common/ccanalyze.c: added even more mnemonics to fix more of #106991. Many more to follow...
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
There is no reason to add a GNOMEVER2.3 keyword to a GIMP bug...
2003-08-09 Henrik Brix Andersen <brix@gimp.org> * gimp/app/widgets/gimpwidgets-utils.[ch]: removed function gimp_menu_path_strip_uline() ... * gimp/libgimpbase/gimputils.[ch]: ... and added it here under the name gimp_strip_uline() * gimp/devel-docs/libgimpbase/libgimpbase-sections.txt: added gimp_strip_uline to gimputils section * gimp/app/plug-in/plug-in.c * gimp/app/widgets/gimpitemfactory.c * gimp/app/widgets/gimptoolbox. * gimp/app/gui/plug-in-menus.c: changed accordingly * gimp/plug-ins/script-fu/script-fu-scripts.c (script_fu_interface): use gimp_strip_uline() to strip mnemonics from script-fu menu paths * gimp/app/gui/vectors-menu.c * gimp/app/gui/templates-menu.c * gimp/app/gui/qmask-menu.c * gimp/app/gui/palettes-menu.c * gimp/app/gui/palette-editor-menu.c * gimp/app/gui/images-menu.c * gimp/app/gui/gradients-menu.c * gimp/app/gui/gradient-editor-menu.c * gimp/app/gui/documents-menu.c * gimp/app/gui/dialogs-menu.c * gimp/app/gui/colormap-editor-menu.c * gimp/app/gui/channels-menu.c * gimp/app/gui/buffers-menu.c * gimp/app/gui/brushes-menu.c * gimp/app/gui/layers-menu.c * gimp/plug-ins/pygimp/plug-ins/clothify.py * gimp/plug-ins/pygimp/plug-ins/shadow_bevel.py * gimp/plug-ins/pygimp/plug-ins/whirlpinch.py * gimp/plug-ins/pygimp/plug-ins/foggify.py * gimp/plug-ins/script-fu/scripts/*.scm * gimp/plug-ins/script-fu/script-fu.c: added mnemonics fixing more of bug #106991 * gimp/app/gui/error-console-menu.c (error_console_menu_update): updated menu item names, added mnemonics * gimp/plug-ins/common/animoptimize.c * gimp/plug-ins/common/animationplay.c: don't prepend every menu entry with "Animation" Basically this means that all menu should contain mnemonics by now. In some submenus which are huge (e.g. <Xtns>/Script-Fu/Logos/) not all items has mnemonics simply because the puzzle was too hard to solve. If you feel like it, please have a go at improving them... What needs to be done in order to close this bug report is to add mnemonics to the rest of the user interface, meaning stuff like tool options and the other dockables and adding mnemonics to plug-in and *-Fu dialogs... Hopefully I will be foolish enough to accept this part of the work as well.
Can this bug be considered as FIXED? I think it can.
I don't think this bug is FIXED yet. We still need a way to specify mnemonics for the submenus added by Script-Fu scripts, Python-Fu etc.
Hi, I don't think it is possible for us to force plug-ins to mnemonicise. As it is, almost everything in the core app has a mnemonic, I think that we should close this bug. Cheers, Dave.
We can not force 3rd party plug-ins to use mnemonics, no. But we should at least use mnemonics for the plug-ins distributed with the gimp.
Bumping milestone to 2.0.1 since fixing this bug requires string changes.
Since it requires string changes it cannot be fixed in 2.0.1 but will have to wait until 2.2.
I just checked all menus and it seems we lack only about 10 mnemonics. I think it's worth the minimal string changes to get this fixed before 2.0. Please cry loud if you disagree, I will fix this tonight and close this bug...
Fixed in CVS: 2004-01-08 Michael Natterer <mitch@gimp.org> * app/gui/layers-menu.c * app/gui/patterns-menu.c * app/gui/tool-options-menu.c * plug-ins/script-fu/scripts/asc2img.scm: added the last missing menu mnemonics. Sorry for the string change but it's IMHO better to fix these 10 strings now than to carry them around during the whole 2.0.x cycle. Finally fixes bug #106991. * plug-ins/script-fu/scripts/asc2img.scm: changed "ASCII to Image Layer" to "ASCII to Layer". We never use the term "Image Layer".
Re-opening and bumping to 2.2 - the submenus in script-fu, filters etc. still lacks mnemonics.
The only thing that seems to be missing here is the Script-Fu submenus. Adding the easy-fix keyword.
This needs to happen before the string freeze. So either we get a patch real soon now, we will have to bump this to the next development cycle.
Apologies for spam-- ensuring Sun a11y team are cc'ed on all current a11y bugs. Filter on "SUN A11Y SPAM" to ignore.
We are into tentative string freeze now. Moving from the 2.2 milestone.
Since only Script-Fu is supposed to be missing, I am changing the component to Script-Fu.
Created attachment 38765 [details] [review] Proposed patch This patch adds a mnemonic to every menu item without one (that I can see); this includes items outside of Script-Fu. I never changed mnemonics for items that already had them, so this should be a low-impact patch. Unfortunately, the abundance of menu items meant I had to add some double-mnemonics, but I think that is better than not having one at all (and HIG seems to agree). Here are the double-mnemonics I added: In Script-Fu/Logos (what a menu!): Pre-existing entry vs New entry Cool _Metal... SOTA Chro_me... Glo_ssy... _Speed Text... Bo_vinated... Car_ved... Glo_wing Hot... _Web Title Header... Chip Awa_y... Cr_ystal... In View, I had to pick a mnemonic for "Show Sample Points" though all letters were already taken and chose T, which conflicts with "Show S_tatusbar." My rationale here is that "Show S_tatusbar" is not frequently used. In View/Zoom, I needed to add mnemonics for the list of 16:1, 8:1, ..., 8:1, 16:1. I didn't think it was possible or worth it to avoid duplicates there.
I don't think we need to add mnemonics everywhere. If mnemonics don't make sense because collisions are unavoidable (like in the View menu), then no mnemonics should be used. Also your patch adds mnemonics to submenus defined in plug-ins and scripts. That must not be done since it puts too much of a burden on the translators. Instead these submenus must be defined in a central place and only there can a mnemonic be added.
collisions don't make mnemonics unusable, though they make them a bit more cumbersome. I am not arguing that -everything- needs mnemonics, only that collisions are not a strong argument against them IMO.
In principal, the patch is good. There are a few points only that should be discussed and might need to be changed. (1) Do we need mnemonics in the View zoom menu? Do we need the view zoom toggle buttons at all now that there's a zoom indicator in the image window? (2) The menu path used with gimp_plugin_menu_register() is supposed to be an identifier. If we add mnemonics here, then we need to make sure that all occurences of this string get mnemonics added. For every different "spelling" we introduce, we create an additional string to translate and the resulting mnemonic becomes indeterminate. I suggest that we don't do mnemonics for plug-in and script created submenus until this has been fixed. The best thing to do at the moment would be to split the patch into a non-controversial part that can be applied immidiately and the remaining bits.
Created attachment 38779 [details] [review] Non-controversial patch OK. This patch takes out all mnemonic collisions as well as all non-leaf menu item mnemonics in the first patch. It does add some leaf mnemonics were it can. I agree with (2), but I don't think collisions are bad and can't see the harm in zoom mnemonics. I left in mnemonics on half the zoom items (subjectively, the more useful half) to avoid collisions. As long as there are no collisions, the mnemonics are fine, right? Fixing non-leaf menu item mnemonics is pretty important, as any break in the mnemonic chain makes them next to useless. One can open the path dialog with Alt+f+d+p, but one can't get to the Swirly pattern very easily (ideally just Alt+x+s+p+s). Unfortunately, adding non-leaf items correctly seems non-trivial to me. Maybe a new bug for that?
I've applied your patch to CVS. I even added the colliding mnemonics in the View menu back since I think it should be either all mnemonics or none. I think a new bug report for the remaining issues would indeed be useful. If you'd open one, we could close this report as FIXED. 2005-03-17 Sven Neumann <sven@gimp.org> * app/actions/layers-actions.c * app/actions/plug-in-actions.c * app/actions/view-actions.c * plug-ins/common/compose.c * plug-ins/common/despeckle.c * plug-ins/common/dog.c * plug-ins/pygimp/plug-ins/py-slice.py * plug-ins/script-fu/scripts/i26-gunya2.scm * plug-ins/script-fu/scripts/news-text.scm * plug-ins/script-fu/scripts/text-circle.scm: applied patch from Michael Terry that adds missing mnemonics (bug #106991).
Cool. I have opened bug #170623 for the non-leaf menu item issue and am closing this one.
Thanks a lot for your help.