Requirements of Input Method Provider Protocol Side
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.
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.
We do this in a two-step process:
- Identify limitations with previous protocols.
- 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.
Singular Keyboard Events Can Not Be Ignored
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)
Popups Can Not Be Rendered in Receiving Client
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)
No Out of Process Input Panels
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)
Popup Does Not Hide on Window Switch
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)
Complex Popups Not Possible
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)
No Tracking of Application Lifetime
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)
Input Method Provider Client Not Easily Switchable at Runtime
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)
Popup State Changes Are Not Synchronized Back With Compositor
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)
Only Single Popup Possible
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)
Implies that Clients Handle Legacy Apps
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)
Final List of Requirements