Adapt UI for system keyboard layout

[ids1024]

Currently, the keyboard and keycode picker are shown based on the keysyms used by the US keyboard layout. This is not ideal for users of non-US layouts. This seems to have confused some users, and improving this could make the software more usable, but this is somewhat complicated to deal with.

How to get the layout to use?

• Use gdk to map keycodes to keysyms
  • This should work, and would show mappings based on the layout currently used by the system. And could automatically change when they keyboard layout is switched.
    • (This is not working quite as expected as I've experimented with it, but needs more testing.)
  • I believe this would require including mappings from all the keycodes used by the keyboard to the Linux/macOS/Windows values, but otherwise should be portable, and Gdk will handle the rest.
  • Limitation: no way to select a layout, only supports the layout currently in use by the system.
• Use libxkbcommon/xkeyboard-config for mapping
  • Shouldn't require anything different on Linux/Windows/macOS
  • Drop down to select any layout
  • Limitation: no way to know what layout is in use by system, or even if it perfectly matches any in libxkbcommon.
  • Displaying all possible layouts becomes complicated (see Gnome Control Center UI for this)
  • I guess selected layout would be stored in home directory?
• Lower level OS specific APIs
  • May be completely different on X, Wayland, Windows, macOS. Probably not practical, but may provide more options than what Gdk exposes.
• Manually implement a few options
  • Could make sure they work well in our UI, for any layouts we offer variants of a keyboard for. But not useful for as many users, potentially.

Keycode picker

• The grouping and order of keycodes may not make sense in another layout. The ; in the US layout is ö in DE, so it logically no longer belongs under symbols, but under alphabet. But automatically determining this for arbitrary layouts may be complicated.

[ids1024]

And looking at it a bit more I'm reminded of how "groups" work in X/Wayland/Gdk (I haven't compared macOS and Windows to see if behavior has subtle differences there).

A keymap has entries for keycodes for diffferent levels and groups. Where level is controlled by shift and altgr, but group is a different layout that is also enabled.

If I enable EN and DE layouts, for instance:

• EN is in the keymap as group 0
• DE is group 1
• Switching between then does not generate an event indicating a keymap change, because they are not different keymaps, only groups in the current keymap.
• It seems no event is generated by Gdk on changing layout? It's only possible to determine the group on KeyPressEvent/KeyReleaseEvent.
  • On Wayland, this would be possible at a lower level (https://wayland.app/protocols/wayland#wl_keyboard:event:modifiers). I don't know about X, macOS, or Windows.
• There also doesn't seem to be a "name" associated with the group, only it's index in the currently list of groups

Dealing with lower level APIs that Gdk may provide more information (like Wayland), but we wouldn't want a solution specific to X, or Gnome.

I now remember this is the part that particularly seemed to complicate things when I looked at it in the past.

[ids1024]

Now that I better understand how Wayland and X handle layouts, I think we could get the layout being used by either in libxkbcommon's format, and parse it to recognize the names of layouts. I see the APIs used on Windows provide a way we could get the layout "names" (whatever that consists of) too. I haven't seen exactly how that works on macOS.

So if we wanted to use keymaps from GDK, with a dropdown to select the group, we might be able to name entries in the dropdown with a (hopefully) relatively small amount of platform specific code. So that may still be an option, though it's not possible in general to know the currently selected group. (The limitations in GDK here seem to match the underlying behavior on X, at least; not sure about Windows/macOS.)