WIP Add cosmic-keymap-unstable-v1 protocol

[ids1024]

Includes example client using cosmic-client-toolkit.

https://github.com/pop-os/cosmic-applets/tree/master/cosmic-applet-input-sources sets the keyboard layout by modifying xkb_config. But it should instead leave the keymap unchanged, and change the group. The applet also doesn't recognize when the group is changed by something else.

KDE has a DBus protocol for this (https://invent.kde.org/plasma/plasma-workspace/-/blob/master/components/keyboardlayout/org.kde.KeyboardLayouts.xml?ref_type=heads). We could have one, but a Wayland protocol is easier to integrate into the compositor, and lets us just use wl_keyboard.keymap to get the current keymap and list of layouts. And privileged Wayland protocols match how our applets typically work.

Zbus is however a bit less verbose that adding a wayland protocol.... something we should work on (Smithay/smithay#1327, etc.).

I guess this will also need an event for the active group, since modifiers (unlike keymap) is only being sent to focused windows).

[ids1024]

I guess we should also figure out how input methods fit in here...

[Consolatis]

A protocol to notify a client using it about group modifier changes regardless of focus should allow for a simple keyboard layout indicator. The question becomes how much the protocol should support outside of that single event, e.g. should it allow the client to set a new global group modifier or not.

The keyboard keymap_format and keymap events may be sent when calling wl_seat.get_keyboard() from what I remember but I think its not actually defined in the protocol. So it might make sense to ensure in the new protocol that the client has bound the keyboard and received the keymap event before starting to listen for the group modifier.

[Drakulix]

So it might make sense to ensure in the new protocol that the client has bound the keyboard and received the keymap event before starting to listen for the group modifier.

Right, I think an extension object for a wl_keyboard makes the most sense here, to make sure the client has actually bound a wl_keyboard. Something like zcosmic_keymap_manager_v1::get_keyboard_listener returning a zcosmic_keyboard_listener which has the necessary events.

[ids1024]

Yeah. I was thinking an extension object would be unnecessary if we just have a request to set the group and not any events. But I guess we need notification of the current group as well, so an extension object makes sense.

(Still annoying the extra boilerplate that adds with wayland-rs... Need to find a better way to manage that.)

We may need to revisit how this works in the future when we properly integrate input methods, but I guess that can be left out for now. I need to look more into how that works on Gnome, etc.