Complex text input in Plasma

[Eike Hein]

On 04/07/2017 04:21 AM, Martin Gräßlin wrote:
> that's actually also a feature of the keyboard daemon we have on X11.
> Only on wayland KWin takes care of it.

Aye, I kind of used KWin as an insert for our whole amalgamation of
shell infra there.


> Ideally we would build up on this. We must not (!) specify an input
> plugin for Qt apps as that would break the virtual keyboard. And even if
> others give up on convergence I still think it's important to support it
> and have it as a target.
> 
> So for input methods KWin would have to provide the UI interaction. Of
> course I do not want to rebuild such a stack but would prefer to be able
> to hook into an existing - I hope that's possible. Maybe a similar
> approach as to how virtual keyboard works: kwin just emulates to the
> qtvirtualkeyboard like if it were in application. So maybe KWin could
> load one of the plugins and interact with them as a proxy for the
> application and just forward the result through the text input interface.

It's super imperative that we work together with the input method
community, then.

This space only has relatively few active developers unfortunately,
and the developer base is already spread thin over multiple
competing stacks. Additionally, much of the development activity
doesn't even happen in the core, but at the fringes, in the form
of IME plugins that are often developed by local communities in
isolation from the core - due to language barrier effects.

If KWin were to introduce another entirely new IME plugin API to
target, we'd further fragment the ecosystem, require IME developers
to duplicate much work, and potentially miss out on work that
continues to be done against other APIs.

(It's important to point out that IMEs are not "done". Emoji IMEs
are a recent development, and things how "How best to type Chinese
into a computer?" are still open questions that see active
experimentation, despite established solutions. Last but not least,
not every popular writing system is covered by free systems
already: There are still entire populations that basically can't
type text on a free desktop system. Bottom line, an important
requirement is future extensibility and trying to funnel work done
our way.)

This fragmentation has a big burden all around - most importantly
on users, because tons of IME plugins are single-person projects
with quality issues. As good platform shepards we should recognize
these systemic problems and try to heal them. The goal being
"bring high-quality text input to as many people as possible" and
any steps measured by that yardstick.

Fortunately the way the stack has stratified, we do control the
UI frontend (or rather we offer one of our own at least, as per
my longer overview). Input Method Panel's popup stuff may wander
into KWin along with other interaction bits - we're free to do
that.

Weng as both a fcitx and Plasma developer is at a critical
intersection here: You and Martin will need to work together on
how fcitx can fit into a kwin_wayland world.

We should also look beyond our borders and look at how ibus
on Gnome/Wayland is being done.


> What I could imagine is that we start with emoji support. Might sound
> weird but is a simplified use case to just "play" with it and
> experiment. We could setup a global shortcut (like the one in GNOME),
> pop up a UI with the emoji selection and go through the text input
> protocol to send the emoji into the application.

We could definitely use that to prototype interaction bits and
stub out the backend part for now. As mentioned ideally the business
logic for it would eventually come from a fcitx/ibus plugin.


Cheers,
Eike