-
Notifications
You must be signed in to change notification settings - Fork 139
Shortcut tweak v2 #739
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Shortcut tweak v2 #739
Conversation
Added a new keymap compile options API: - `xkb_keymap_compile_options_new` - `xkb_keymap_compile_options_free` - `xkb_keymap_new_from_names2` - `xkb_keymap_new_from_file2` - `xkb_keymap_new_from_buffer2` This interface allows to configure keymap options that cannot be passed as flags. This is aimed at *server* applications, since the only planned options affect the handling of the keyboard state. Note: `xkb_keymap_new_from_string2` was not added due to its low added value compared to using `xkb_keymap_new_from_buffer2` with `strlen`.
8226233 to
ab503ae
Compare
Currently each toolkit (Gtk, Qt, etc.) implements its strategy to deal with keyboard shortcuts on non-Latin layouts. There are some edge cases where this does not work: - Punctuation is usually not remapped. E.g. the standard Israeli layout cannot remap its key <AD01> “slash” to the US layout “q”. - If one have multiple Latin layouts, shorcuts may be positioned differently. E.g. US Qwerty and French Azerty have different positions for Ctrl+Q, while the user might want all shortcuts to be positioned independently of the layout. This commit enables tweaking keyboard shortcuts by adding the option to switch to a different group after pressing some modifiers, typically Control, Alt or Super. The target group can be set for each group, although the most common use case would probably be the same target for all layouts. Added to the keymap compile options API: - `xkb_keymap_compile_options_set_modifier_mask` - `xkb_keymap_compile_options_set_shortcuts_reference_layout`
ab503ae to
60d4bba
Compare
|
@bluetech @whot @mahkoh While this could be implemented in the compositors, it seems that such hack would be better handled in the lib. Also, this is a bit too hacky for my taste. Do you have a better idea how to handle this? @bam80 and @Jules-Bertholet may want to try this up-to-date PR. |
|
any updates? |
|
@saeedmfarahani No update. It is unclear if the best route is to implement this in the lib or to let each compositor implements its own strategy. I asked to some but did not get an answer. This approach feels too hacky anyway, so I will have to rethink a better solution. |
|
Closing in favor of #929. Hopefully that will be the last attempt! 😅 |
Currently each toolkit (Gtk, Qt, etc.) implements its strategy to deal with keyboard shortcuts on non-Latin layouts. See e.g.:
xkeyboard-config)Tweak keyboard shortcuts by adding the option to switch to a different group when some modifiers are active (typically
Control,AltorSuper). The target group can be set for each group, although the most common use case would probably be the same target for all layouts.This can be alternatively activated with the environment variables
XKB_UNSTABLE_EXPERIMENTAL_SHORTCUT_MASKandXKB_UNSTABLE_EXPERIMENTAL_SHORTCUT_TARGET_LAYOUTS1. This enables to use the new feature even if the DE does not implement a UI to configure it. While the names suggests that this setting method is temporary, I am unsure we should ship it: I do not want to see this setting method broadly used so that we cannot change/remove it later. It is more a mean forearly adoptershackers to test the feature by installing their own local version of libxkbcommon.I need help to rephrase the doc: this is more a hack than a tweak, as we are breaking the XKB protocol by not following its computation rule of the effective group. But Wayland requires only an effective group2, so it is okay-ish.
Fixes #753
TODO:
This is a refactor of #523, which got out of sync and used a more complex (broken?) approach.
Footnotes
Actually the env variable will also activate this processing in clients for now, but this is a no-op, as the layout is set by the compositor, which would have already re-target it for shortcuts, if necessary. ↩
See:
wl_keyboard::modifiers↩