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.

[Conan-Kudo]

FYI @Zamundaaa

[Consolatis]

This looks great. Do you intend to propose it upstream as well? In either case labwc will consider adding support for it.
Some way for an external application like a panel to show and set the current layout is one of the missing pieces and gets mentioned fairly often.

[Conan-Kudo]

FWIW, KWin has an alternative mode where it just responds to locale1 settings too. Fedora KDE uses this for the live session. And COSMIC has this capability too (since it was implemented in pop-os/cosmic-settings-daemon#35). So what is this protocol for now?

[Consolatis]

So what is this protocol for now?

Compositors that don't want to depend on dbus for basic functionality. Additionally, at least from a quick glance of the linked PR the dbus interface appears to set the whole xkb config rather than just changing the group modifier.

[Conan-Kudo]

D-Bus is required for basic functionality already. It's been that way for (conservatively) at least 15 years.

[ids1024]

Maybe keymap isn't the best term for this protocol, but I don't know what is. (cosmic-keymap-group? cosmic-keyboard-group?).

It simply provides the group number currently active in the keymap (which is exposed by wl_keyboard::keymap) and a way to set it. So together it's possible to show a list of keyboard layouts, and select one.

I don't believe locale1 does anything like that, or would be intended to. That defines what keymap to use (with one or more groups).

Do you intend to propose it upstream as well?

Yeah, it seems like it could be reasonable to propose upstream, and I was thinking of doing so. It's a fairly clean and simple protocol if there aren't concerns about how it works. If labwc is interested I guess that's additional reason to.

[Consolatis]

Maybe cosmic-keymap-layout would work? (libxkb uses xkb_layout_index_t and xkb_keymap_layout_get_name() )