shared keyboard accelerators

[david gowers <neota softhome net>]

the following is a proposition regarding shared keyboard accelerators. i 
posted an earlier version of this a few days ago on the gimp-devel list.
sven said essentially 'these changes to gimp are desirable, but not 
appropriate to add to gimp before 2.0 has been released'. 
hopefully i can proceed on the gtk side of things in the meantime.
is a patch to implement the specified changes likely to be accepted?
any suggestions to improve the interface ? (see 'how to interface with that?')


****


   ++++ Shared keyboard shortcuts ++++

currently, keyboard shortcuts only work in their specific context.

having shortcuts that belong to more than one context
would help greatly. for instance palette construction would be much
much quicker if i  could assign a shortcut to <palette editor>'add' and
share that with the colorpicker, so i could eg. pick color, 'a', pick
color,'a' until the palette is finished. gradient creation could be
speeded up similarly (stack up colors in the 'save to' slots, then use the 
saved colors
to create a large chunk of gradient quickly).

. likely format for shared shortcuts would be:

"(gtk-shared-accel-path 
<ColorEditor,GradientEditor,PaletteEditor><PaletteEditor>/New Color)"

(note that ColorEditor gets its own accel group, as would every
selection dialog eg Brushes,Gradients..)

so you can share key-accels for specific menu items rather than sharing
the whole class. a shared accel would require the accel being shared to
be already defined. this can be done by writing shared accels to menurc
last.

making the accels visible would mean adding an item to the menu, like
"(PaletteEditor/New Color)". note the brackets.
gtk would show the shortcut like this:
"(a)" rather than "a", to denote that you must go to, in this case, the
palette editor, if you want to change the key combination for that accel.


how to interface with that?
'delete' to remove the current context from the list of user-contexts
for a shared accel.
adding would require an additional menu item at the bottom of the
menu, like an inversion of the 'tearoff' menu item, on which you could 
press 'insert' to add a shared accel or add current context to the users
of an existing shared-accel.

making the accels visible would mean adding an item to the menu, like
"(PaletteEditor/New Color)". gtk would show the shortcut like this:  
"(a)" rather than "a", to denote that you must go to, in this case, the
palette editor, if you want to change the key combination for that accel.
perhaps this can be denoted by text color instead.

(how to interface needs improvement.)

summary :

gimp-side changes required: add accel-paths for all registered dialogs
(all the dockable ones at least). as a consequence, many more accels could
be assigned.  for instance, palette editor is something that should start with
shortcuts for all its menu operations, since it has so few.

gtk-side changes required: menudump support for shared-accel-path, menupaths 
browsing in some form, various changes to gtkmenu*.c including drawing + 
keypress handling. (anything else?)

++ new material ++

possible to share whole menus/submenus? (eg all the layers/ stuff can be moved
to the layers dialog, and only shared at the users' option.)

shortcuts assignable to the selection of specific 
items(gradients/palettes/etc)? in operation, it could be something like 
pressing '3' to select the brushes dialog
then 'a' to select a one-pixel brush. given dialogs having their own
accel-group, you could have loads of accels just to select specific items.

(cut stuff that's irrelevant to gtk)

****

initially i want to implement the basic mechanisms for sharing single menu 
items. the other ideas are extensions of that.