Solving Shortcuts Keys behavior

When trying to fix this bug, there are lateral effects that can happen after fix the bug. See this filed bug.
To understand how it can be solved it is needed to first understand how the keyboard events are handled.
When a keyboard event happens, it is (by default) first handled by the top window level key event dispatcher. After that it is not fully handled then it is passed to the widget that has current focus to be handled by it.
See more detailed explanations here: … 00038.html and subsequent sub threads.
So the initial solution I wrote for the problem was to override the default keyboard event handler for the top level windows and see if the keyboard event is handled by the focused widget.

For instance for the Toolbox I added:

bool Toolbox::on_key_press_event(GdkEventKey* event) { Gtk::Widget* focused_widget = get_focus(); if(focused_widget->event((GdkEvent*)event)) return true; return Gtk::Window::on_key_press_event(event); }

This way, if the current focused widget can handle the keyboard event then it returns true, otherwise it passes the keyboard event to the top level window key event dispatcher, returning true if the event is dispatched.

So if before pass the event to the focused child widget, filter the event to only pass some type of events to the child focused widget, then the event will be handled correctly.

The problem is to decide which events should be handled by the top level window key event dispatcher first and which not.

The default keyboard shortcuts are defined in the App class when the user interface manager is initialized:

[code]#define ACCEL(accel,path)
Gtk::AccelKey accel_key(accel,path);
Gtk::AccelMap::add_entry(accel_key.get_path(), accel_key.get_key(), accel_key.get_mod());

ACCEL(“a”, “/action_group_state_manager/state-normal”);
Since the keyboard shortcuts can be changed by modifying the accelrc file that is read when settings are loaded we need to decide which keyboard events can be handled by the action that it would trigger and not directly by the keyboard combination itself.
We can retrieve the Gtk::AccelMap from the current window and compare the keyboard event with the accelerators that we consider that the window must handle before the focused children. It has to be done by searching by the path of the accelerator (that is the action triggered by the key event).

So for each top level window: Dockable, Canvasview, Toolbox
we have to define which actions has to be handled by the top level keyboard dispatcher first and which not.