We at Openismus combined our experiences in the Maliit input method framework and Waylandinput methods and added support for Wayland input methods to Maliit. This allows using Maliit as a virtual keyboard under Weston/Wayland beside the demo weston-keyboard. To try it out use maliit-framework from master and Weston from our github repository and compile it with Qt 5 and qmake CONFIG+=wayland, maliit-plugins (from master) needs to be build with qmake CONFIG+=disable-nemo-keyboard.
There is no EFL support in Maliit (and no Maliit support in EFL) but since there is wayland input method support for EFL available one can just use Maliit with EFL applications under Wayland. This shows one of the advantages of the Wayland input methods, that input method frameworks do not need explicit support for all kind of UI toolkits anymore.
The current plan is to get input method support into Wayland 1.2. Adding support for Wayland input method to Maliit allowed us to discover some missing features which we will work on next together with some more improvement suggestions to get the input methods really ready for Wayland 1.2.
Over the last years, we at Openismus have worked on input methods for mobile devices (see for example the Maliit input method framework). During that work we noticed that there are several problems caused by the toolkit-level interface between the input method system and the applications (beside having to implement interfaces for every toolkit, like GtkIMContext and QInputContext). One of this problems is synchronizing events happening to the focus window and the virtual keyboard window. Therefore good platform integration of input methods such as virtual keyboards requires additional window management policies, as the window manager has to gain knowledge about input methods. The compositing window manager on Nokia’s N9 serves as an example for the amount of required integration. It also taught us about what can go wrong and that Xorg induced latency is a hard problem to solve (see Compositing in Maliit). There is also the XIM X extension which integrated input methods on the X level, but its limitations and complexity puts it as a second choice compared to the toolkit interfaces mentioned above (especially since it does not manage to solve there problems).
The move from Xorg to Wayland offers the possibility to move the input method system from the toolkit level down to the display server, as discussed in our Wayland Input Method System Proposal. Last week, Openismus let me work on a small prototype technical demo for Weston (the Wayland reference compositor) which implements some of the ideas in that proposal. This should be useful for testing the idea of having the input method system integrated in Wayland.
New Wayland interfaces
Standalone input method system with text and input method protocols
The prototype defines three interfaces. The first is the text_model, which is used to communicate from the application/toolkit side with the input method system. It provides the input method system with all required information about the active text, such as selection, surrounding text and cursor index. The application receives events over this interface, such as preedit and commit, from the input method system. For the prototype, I implemented an example editor client, which uses the text model to send the surrounding text to the input method system and receives commit events.
The second interface is the input_method interface which is used to communicate between the input method and Wayland. For the prototype we use a really simple keyboard client which just sends commit events when pressing one of the keys.
The third interface is used to register the keyboard surface as an input panel on the shell. I added the input_panel interface to the desktop shell protocol. This allows the shell to stack the keyboard surface into the right layer (for the prototype I used the panel layer). Additionally, the prototype adds support to the shell to show the keyboard only when a text model is active.
The prototype is the outcome of less than a week of coding, but it already uses some of the concepts we learned while working on Maliit. It should serve as a baseline for further Wayland input method system integration, even if many basic items are missing. For instance, there is no integration with hardware keyboard events, nor keyboard focus (which is handled by wl_seat in Wayland). Nevertheless I will polish my patches a bit and send them to the Wayland mailing list for integration into Weston, so that they can be used for more work on input methods in Wayland/Weston. My colleague Michael will present this work at aKademy in two weeks, which will be a good opportunity to discuss the possibilities of such an input method system in Wayland.
Currently Maliit depends heavily on X for core functionality (for example assigning the virtual keyboard to the application via transient for window hint) but also for some optional features like self compositing, which was implemented to dramatically improve the performance on Harmattan by doing the compositing inside Maliit itself instead of inside the X compositor.