You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
At the moment there's a problem with keybinding creation and processing.
When a keybinding is accessed using shift such as the zoom in keybinding
Ctrl-+ which on English keyboard requires pressing <Ctrl><Shift>=, the
<Shift> key is preserved right now. This is visible when changing
keybindings - pressing the above key combination leads to
<Primary><Shift>+. This is incorrect - the keybinding should either
be <Primary><Shift>= or <Primary>+ but in <Primary><Shift>+ there's
extra <Shift> which leads to problems.
On linux the problems aren't so much visible - the problem is visible
when changing keybindings as mentioned above. Even though this
particular keybinding isn't executed through on_key_press_event()
because the combination <Primary><Shift>+ doesn't correspond to the
default <Primary>+ value, it's executed by GTK as an accelerator so
the problem isn't directly visible.
This might however break when a user modifies this keybinding to the
wrong value <Primary><Shift>+ and when the user is using multiple
keyboards such as English where + has to be accessed over shift
and German where typing + doesn't require shift. The keybinding will
stop working on the German keyboard in this case because of the
extra shift.
On MacOS the accelerator isn't executed for some reason and non-
letter keybindings don't work when shift is used.
To fix the issue we can use gdk_keymap_translate_keyboard_state()
which reports "consumed" modifiers - that is those which lead to
typing the secondary character. However, we don't want this to happen
when typing alphabetical characters because it's easier to notice
the use of shift in <Ctrl><Shift>r than in <Ctrl>R. Modifier
consumption is undone in this case.
Should also fix #694
https://github.com/geany/geany/pull/1633
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.