Sophisticated use of accelerators

[Simon Fuhrmann <SimonFuhrmann gmx de>]

Hello Murray, hello list-guys.

This question is towards sophisticated use of accelerators in gtkmm:

My application uses a system where some menus (thus menu items) are
dynamically added to and removed from the user interface. But some parts of
the menu interface are fixed. So, accelerators need to change depending on
the mode of the application. I'll try to give an abstract example:

If the application is in mode M1, I want the menu A, B and C to be
displayed. If the mode changes to M2, menus B and C will disappear and
menus D and E will be introduced (and by the way, A is the fixed menu
and will always be present, regardless of the mode).

It should be possible that menu items (in different modes) share the same
hotkey, so hotkeys need to be removed and added dynamically.

Back to the example: Suppose menu B has menu item Ba with hotkey
<Control>a, and menu D has menu item Da with the same hotkey. Consequently
accelerators have to "change" if the mode changes from M1 to M2.
"Change" means that all accelerators for menu B and C need to be
removed and accelerators for menu D and E need to be inserted.

The question is now: Whats the best was to implement this feature? Should I
use one
  
  Glib::RefPtr<Gtk::AccelGroup> agroup;

for each mode (is it possible to add more than one AccelGroup to a
Gtk::Window), or should I use just one AccelGroup for all bindings? My
understandings are, that a window can only have ONE AccelGroup, so I need
to update hotkeys as soon as the menu changes (on mode change).

If there must only be one AccelGroup for all menus, do I need to remove
all accelerators for the mode-to-be-left myself or will gtkmm do that for
me?

Since I don't want to change accelerators for menu items during runtime,
the gtk_accel_map is not the solution for my problem, is it?

It would be great if someone could give me a hint about what steps I
need to understand and accomplish to implement this feature.

Thanks in advance,
Simon Fuhrmann

-- 
Simon Fuhrmann <SimonFuhrmann at gmx.de>
Wer Rechtschreibefehler entdeckt, darf sie behalten.