Use undocumented GtkKeyHash, this is what powers GTK accelerators internally: header, source, example.

Its unlikely that making Geany depend on undocumented internals of GTK will be accepted.

Add missing hotkeys to the AccelGroup and drop the custom hotkey handling in on_key_press_event.

Remake all hotkey handling using Accelerator Maps.

These require the accelerator to have a menu item to map to, whilst I personally think thats a fine goal, at the moment its not the case in Geany, nor in plugins. Also any change would have to maintain the current plugin interface.

Also one of the contributors had a first look at accelerators and came upon the stumbling block that they only allow one closure per binding, not sure if they found any workaround to that.

Remake all hotkey handling using Bindings.

Its not clear how the keybinding UI would work with keybinding files, there does not seem to be a way to load, parse and save the files.

Any of the above appear to require significant changes to Geany and plugins and certainly will not happen quickly, or at all if there is no interest in providing the effort. Geany is volunteer developed software and nobody can be instructed/tasked/forced to do anything.

I suggest to stop enabling-disabling cut/copy actions on the Edit menu opening. It can be easily done by commenting out ui_update_menu_copy_items and doesn't lead to any problems, only visually the menu entries will be enabled all the time.

Downgrading the UI for everybody in favour of a small number of users is not an acceptable approach IMHO.

You have not yet shown why the suggested workaround (rebind the problem keys for the new keyboard layout and if you use both layouts have separate configuration directories for each (-c option)) does not work, so implementing major changes or UI downgrades for everybody is inappropriate at this point. .

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