Wlroots: Choose and support a text input protocol

[dcz-purism]

Currently, wlroots doesn't support any protocol to send text coming from input methods to applications.

There are 3 contenders:

| Protocol | Defined in | Servers supporting | Clients supporting |
|------|-------------------------------------------|-----------------|-----------------|
| text_input_unstable_v1 | wayland-protocols | ? | Qt (incompletely), gtk3 via maliit |
| [zwp_]text_input_unstable_v2 | jpetersen's wayland-protocols | kwin 5.7+ | Qt 5.7+ |
| gtk_text_input | mutter | mutter | [gtk3 > 3.22.28][gtk-gtk3], gtk4 > 3.93.0 |

In order to support the use case, one or more of the protocols would need to find its way to wlroots. The following options appear:

• support v1 and convince people to use the maliit plugin for GTK
• support both v2 and gtk in order to make both Qt and GTK applications work
• convince GTK and Qt to converge on a single protocol and support that

The author of the v1 protocol admits it has shortcomings, which spawned the v2. It would be best not to use this protocol.

Supporting both v2 and gtk protocols would introduce complexity not just to wlroots, but to any other compositor wanting to support a wide range of applications, therefore it's not ideal.

That leaves supporting only one of v2 and gtk on the table. Both have been implemented in toolkits as well as compositors. The gtk version wants to become v3 eventually. I've been told v2 is still rather tied to maliit and its quirks.

On the technical side, gtk is an update to v2, and it simplifies the protocol by removing:

• explicit setting of the language
• explicit showing the input panel
• managing display style
• managing cursor position
• handling raw keysyms.

Choosing the alternative largely depends on getting the Qt and GTK communities on board at this point.

[ddevault]

Okay, let's draw up a v3 based on gtk's protocol and send it along to the stakeholders for consideration.

[emersion]

A v2 patch has been submitted: https://patchwork.freedesktop.org/patch/90148/

[dcz-purism]

Now the v3 patch is ready too: https://patchwork.freedesktop.org/patch/209838/

[gatispaeglis]

Thank you for the nice summary :)

The author of the v1 protocol admits it has shortcomings, which spawned the v2. It would be best not to use this protocol.

In the linked comment it does not admit anything AFAICT, it explains why "built by Openismus" is irrelevant for the protocols usability. I am a Qt developer and I have been looking at v2 for few days and the only issue that I see with the protocol is the sending of _keysym_. I see that that part has been removed in v3 - "handling raw keysyms."

The gtk version wants to become v3 eventually.
On the technical side, gtk is an update to v2

This is only confusing for the rest of the community. v2 is not even included in the wayland-protocols repository. v3 implies the "next/better version", but all it is is an alternative version to v2. Was anyone from Qt participating in reviewing and branding it as the next/better version of the protocol?

I've been told v2 is still rather tied to maliit and its quirks.

It would be nice to know what is meant by that. Could be some misunderstanding.

[..] v2, and it simplifies the protocol by removing:

I agree that a code often can be simplified by removing too much verbosity, but in this case it does not look like a simplification. The protocol was reduced to match with GTK APIs https://developer.gnome.org/gtk3/stable/GtkIMContext.html

v2 is a direct mapping to QPlatformInputContext - https://code.woboq.org/qt5/qtbase/src/gui/kernel/qplatforminputcontext.h.html

QPlatformInputContext has more functionality than GtkIMContext, hence the protocol (v2) has more events/requests compared to v3.

And as stated in https://bugzilla.gnome.org/show_bug.cgi?id=698307#c21 due to limitations in GtkIMContext API, they have implemented some hacks to showing/hiding input panel. I don't know the details, but it looks like GtkIMContext API is limited and now the same limitation is enforced on the rest of the community with v3.

Qt complex input plugins support text styling and that has been removed in v3. How does Wayland project expect those plugins to continue working when this functionality has been trimmed from the protocol?

It is good that it is acknowledged that sending keysym is bad. It results in really ugly/hackish code. e.g. virtual keyboard implementation does not know/care about X11/XKB keysyms, but since protocol (v2) requires them, then some ugly code appears to make it work.

In Qt, vkb input method and for example ibus input method use the same interface - QPlatformInputContext. I see that wayland project wants to separate this into text-input + virtual keyboard protocols. The proposed virtual keyboard protocol looks over complicated from the initial look. It looks like it requires scan codes.. why would vkb keyboard know about scan codes? The only defined keymap in wayland protocol is XKB, why would i want to map my vkb to a complex legacy/undocumented XKB keymap? Why would I want to send modifier state? Can't the keyboard handle all that internally and then just send to a client the final utf8 encoded character? The proposed protocol supports only keyboard as client, but text-input-v2 supports in-process vkb.

[emersion]

Closing this since v3 has been merged upstream: https://github.com/wayland-project/wayland-protocols/commit/db152d7c6f53adb60db8dfc046604a487002d927