Skip to content

Conversation

@wismill
Copy link
Member

@wismill wismill commented Oct 4, 2024

Currently each toolkit (Gtk, Qt, etc.) implements its strategy to deal with keyboard shortcuts on non-Latin layouts. See e.g.:

Tweak keyboard shortcuts by adding the option to switch to a different group after pressing 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.

This also introduces the keymap compile options API.

This can be alternatively activated with the environment variable XKB_TARGET_SHORTCUT_LAYOUT1. The target group is then the same for all groups. This allow to use the new feature even if the DE did not implement a UI to configure it.

TODO:

  • Tests
  • Support latch & lock?
  • Doc
  • Fix the new FIXMEs
  • Move option API to other MR?
  • Commit messages
  • Remove environment variable support?
  • Log entry

Footnotes

  1. 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.

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.
@wismill wismill added compile-keymap Indicates a need for improvements or additions to keymap compilation state Indicates a need for improvements or additions to the xkb_state API labels Oct 4, 2024
@wismill
Copy link
Member Author

wismill commented Oct 4, 2024

Note that there is another way of handling this: set the shortcut keysyms directly in the keymap (à la macOS), by defining new key types with e.g. map[Control] = levelX, etc. Some issues:

  1. We need entries for every modifier combination.
  2. We need the corresponding preserve entries, e.g. preserve[Control] = Control.
  3. It is not easy to select the correct target layout using rules.

We could alleviate this by modifying the keymap on the fly from a given simple source → target layout mapping. Here we could have also fine-grained control on whether the punctuation keysym are affected or not, contrary to the current PR where it’s all-in or all-out.

A similar approach is to use the trick that we can have map[None] = level2 and use a mask with unmapped modifiers in the key type.

@wismill wismill added this to the 1.11.0 milestone Jan 22, 2025
@ezhan
Copy link

ezhan commented Mar 29, 2025

As I understood, it is a Qt issue?
I've opened an issue against Qt: https://bugreports.qt.io/browse/QTBUG-135336

Will see that that brings.

@Jules-Bertholet
Copy link
Contributor

I would appreciate it if XKB_TARGET_SHORTCUT_LAYOUT also accepted a comma-separated list of layouts, to configure each group separately.

@wismill wismill mentioned this pull request May 2, 2025
4 tasks
@wismill
Copy link
Member Author

wismill commented May 2, 2025

Closing in favor of #739.

@wismill wismill closed this May 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

compile-keymap Indicates a need for improvements or additions to keymap compilation state Indicates a need for improvements or additions to the xkb_state API

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants