Requirements of Input Method Provider Protocol Side

Introduction

Definitions

Input method providers are software components, that augment the input by physical devices. They are also often just called input methods or input method editors (shortened to IME).

The input method provider protocol side are all Wayland protocol interfaces that input method providers use to enable their input method functionality in a Wayland session.

Context

This is part of #39 to develop the next generation of Wayland input method support. We use this ticket to gather requirements that input method providers might reasonably place onto this next generation. These providers bring with them the experience they gathered working with the input-method-unstable-v1 and v2 protocols and can best propose ideas to improve it.

Method

We do this in a two-step process:

1. Identify limitations with previous protocols.
2. Classify resolutions for these limitations either as:
   • hard requirement: any new protocol must remove the limitation.
   • soft requirement: any new protocol should aim for removing the limitation.
   • ignore: a new protocol can ignore the limitation.

Limitations of Previous input-method Protocols

Until now input method providers on Wayland rely mostly on input-method-unstable-v1 and input-method-unstable-v2 protocols. While these offered already a good basis to build input methods against, providers identified the following areas where a new protocol could be improved by.

input-method-unstable-v2

Singular Keyboard Events Can Not Be Ignored

Description:
IMEs can obtain a keyboard grab and get all keyboard events. Sometimes the IME will not handle the keyboard event and will want to forward it to the focused application. Right now IMEs will need to use the virtual-keyboard protocol to re-inject the events into the compositor.

Instead the IME should be able to tell the compositor that it didn't handle an event and let the compositor forward it to the focused application.

Discussion: #40 (comment 835289)
Classification: Hard/Soft/Ignore

Popups Can Not Be Rendered in Receiving Client

Description:
In terms of gaming, the full screen game may prefer to work without composition for performance reason. So having the ability to let client application to render its own popup should be supported ideally.

Discussion: #40 (comment 835295)
Classification: Hard/Soft/Ignore

No Out of Process Input Panels

Description:
Some input method providers (IBus) integrate deeply with the shell. Panels of the input method are displayed by external processes. These panels need to be identified so the compositor places them accordingly.

Discussion: #40 (comment 835312)
Classification: Hard/Soft/Ignore

Popup Does Not Hide on Window Switch

Description:
Input method does not get informed at the right moment when another text input field in another window is activated leading to flicker.

Discussion: #40 (comment 835314)
Classification: Hard/Soft/Ignore

Complex Popups Not Possible

Description:
The popups provided in the protocol are very simplistic as in a single wl_surface only being placed relative to a fixed rectangle. This doesn't allow input methods to show more complex multi-layer popups with additional information.

Discussion: #40 (comment 835315)
Classification: Hard/Soft/Ignore

No Tracking of Application Lifetime

Description:
The input-method v1 protocol created and destroyed the input context object upon focus in/out. But input-method v2 doesn't have input context concept.

Discussion: #40 (comment 835316)
Classification: Hard/Soft/Ignore

Input Method Provider Client Not Easily Switchable at Runtime

Description:
There can only ever one client bind to the input-methods interface and it can not be switched with another one unless the client unbound before that. This makes it difficult to switch the input method provider, which would need to be instructed before that to disconnect.

Discussion: #40 (comment 836841)
Classification: Hard/Soft/Ignore

Popup State Changes Are Not Synchronized Back With Compositor

Description:
When compositor sends a new state, it does not know when the input method provider has repainted the popup surface to e.g. a new size.

Discussion: #40 (comment 846709)
Classification: Hard/Soft/Ignore

Only Single Popup Possible

Description:
Input method providers can only set a single popup. For example could be useful for word suggestions below the input field and dictionary above. Needs positioning requests.

Discussion: #40 (comment 847039)
Classification: Hard/Soft/Ignore

virtual-keyboard-unstable-v1

Implies that Clients Handle Legacy Apps

Description:
The virtual-keyboard usefullness should not rely on input methods having to deal with legacy applications that don't support the text-input protocol. Instead that should be handled by the compositor alone.

Discussion: #40 (comment 836488)
Classification: Hard/Soft/Ignore

Final List of Requirements

Hard Requirements:

• ...

Soft Requirements:

• ...