-#endif
-#endif
-
-
- DEBUG_TRACE (DEBUG::Accelerators, string_compose ("Win = %1 focus = %7 Key event: code = %2 state = %3 special handling ? %4 magic widget focus ? %5 allow_activation ? %6\n",
- win,
- ev->keyval,
- ev->state,
- special_handling_of_unmodified_accelerators,
- Keyboard::some_magic_widget_has_focus(),
- allow_activating,
- focus));
-
- /* This exists to allow us to override the way GTK handles
- key events. The normal sequence is:
-
- a) event is delivered to a GtkWindow
- b) accelerators/mnemonics are activated
- c) if (b) didn't handle the event, propagate to
- the focus widget and/or focus chain
-
- The problem with this is that if the accelerators include
- keys without modifiers, such as the space bar or the
- letter "e", then pressing the key while typing into
- a text entry widget results in the accelerator being
- activated, instead of the desired letter appearing
- in the text entry.
-
- There is no good way of fixing this, but this
- represents a compromise. The idea is that
- key events involving modifiers (not Shift)
- get routed into the activation pathway first, then
- get propagated to the focus widget if necessary.
-
- If the key event doesn't involve modifiers,
- we deliver to the focus widget first, thus allowing
- it to get "normal text" without interference
- from acceleration.
-
- Of course, this can also be problematic: if there
- is a widget with focus, then it will swallow
- all "normal text" accelerators.
- */
-
- if (!special_handling_of_unmodified_accelerators) {
-
- /* XXX note that for a brief moment, the conditional above
- * included "|| (ev->state & mask)" so as to enforce the
- * implication of special_handling_of_UNMODIFIED_accelerators.
- * however, this forces any key that GTK doesn't allow and that
- * we have an alternative (see next comment) for to be
- * automatically sent through the accel groups activation
- * pathway, which prevents individual widgets & canvas items
- * from ever seeing it if is used by a key binding.
- *
- * specifically, this hid Ctrl-down-arrow from MIDI region
- * views because it is also bound to an action.
- *
- * until we have a robust, clean binding system, this
- * quirk will have to remain in place.
- */
-
- /* pretend that certain key events that GTK does not allow
- to be used as accelerators are actually something that
- it does allow. but only where there are no modifiers.
- */
-
- uint32_t fakekey = ev->keyval;
-
- if (Gtkmm2ext::possibly_translate_keyval_to_make_legal_accelerator (fakekey)) {
- DEBUG_TRACE (DEBUG::Accelerators, string_compose ("\tactivate (was %1 now %2) without special hanlding of unmodified accels\n",
- ev->keyval, fakekey));
-
- GdkModifierType mod = GdkModifierType (ev->state);
-
- mod = GdkModifierType (mod & gtk_accelerator_get_default_mod_mask());
-#ifdef GTKOSX
- /* GTK on OS X is currently (February 2012) setting both
- the Meta and Mod2 bits in the event modifier state if
- the Command key is down.
-
- gtk_accel_groups_activate() does not invoke any of the logic
- that gtk_window_activate_key() will that sorts out that stupid
- state of affairs, and as a result it fails to find a match
- for the key event and the current set of accelerators.
-
- to fix this, if the meta bit is set, remove the mod2 bit
- from the modifier. this assumes that our bindings use Primary
- which will have set the meta bit in the accelerator entry.
- */
- if (mod & GDK_META_MASK) {
- mod = GdkModifierType (mod & ~GDK_MOD2_MASK);
- }
-#endif
-
- if (allow_activating && gtk_accel_groups_activate(G_OBJECT(win), fakekey, mod)) {
- DEBUG_TRACE (DEBUG::Accelerators, "\taccel group activated by fakekey\n");
- return true;
- }
- }