Re: Sophisticated use of accelerators

[Carl Nygard <cjnygard fast net>]

On Tue, 2005-03-08 at 20:27 +0100, Simon Fuhrmann wrote:
> 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.

One idea:

sigc::signal<void> redirectorA;
vector<sigc::connection> modeB, modeC;
modeB.push_back(redirectorA.connect(sigc::mem_fun(*this, Foo::MenuBA)));
modeC.push_back(redirectorA.connect(sigc::mem_fun(*this, Foo::MenuCA)));

for_each(modeB.begin(), modeB.end(), mem_fun(&sigc::connection::block));
for_each(modeC.begin(), modeC.end(), mem_fun(&sigc::connection::unblock));

Now just connect the accelerator to the redirectorA signal and
block/unblock the slot connections as you switch the menus around.



-- 
Carl Nygard <cjnygard fast net>