I'm not either fond of changing something so fundamental when it works; but apparently it's actually not working properly.

Thanks for understanding the importance of this bug.

I'd like to explain a bit more about the situation here, how it all works.

On key press we have two variables: keyval and hardware_keycode. keyval is the entered symbol, hardware_keycode is the pressed physical key, looks simple. If we were parsing input, we'd convert keyval integer to unicode character and use it, simple too. Since here we are looking for hotkeys, we should check the physical key. Ok then, let's compare hardware_keycode with... what? With GDK_KEY_A? No, it is a keyval. Do we have an equivalent keycode constant? No, we don't. At least not in GDK. If we're on Windows, we can compare with VK_A, on Mac we can compare with kVK_ANSI_A, and it will be the same key A (actually, only in QWERTY layout, but that's another story). On X11 keycodes are hardware/driver dependent, one keysym (keyval in X11 terms) may correspond to multiple keycodes. GDK doesn't abstract from us the keycodes given by the system. Although I think it would be great to have GDK Virtual Key Codes, there are none. hardware_keycode is a raw value that is different between platforms and even can change at runtime.

GDK handles this keyval-keycode matching via GdkKeyHash, it is used internally in accelerators and bindings.

Although it is undocumented, in my opinion it is the simplest way to fix the issue. Just fill the hash on start with a hotkey's keyval as a key and with a pointer to GeanyKeyBinding as a value, modify when user changes a hotkey, match the key in on_key_press by a simple lookup call.

If it'll be decided against direct GdkKeyHash use, then to reimplement it on top of the current Geany hotkey handling you'll need to add an array of hardware_keycodes to the GeanyKeyBinding struct, fill it using gdk_keymap_get_entries_for_keyval on start, free and refill it on keys-changed signal and when user changes a hotkey, then modify on_key_press handler to check hardware_keycodes instead of a keyval (use GdkKeyHash as a reference).

If somebody is ready to do some refactoring, moving all handling to accelerators or bindings is the way to go. I'd like to add that menu mnemonics take precedence over accelerators, so it won't be possible by default to override Alt+S and other menu items mnemonics, like it can be done currently, but it should be possible to override this behavior by using gtk_accel_group_activate on key press.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.