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
