Maliit/Ideas/Supporting Non X11 Platforms

Revision as of 12:30, 26 April 2011

At the moment, the X11 platform is the only platform supported by the Input Method. This page describes the approaches that can be taken to support non-x11 platforms. When we are talking about non-X11 platforms the following feature may be affected:

• Input method's process host
• Self-compositing
• Hardware keyboard mapping
• D-Bus API input context connection

The ideas in this page basically built on using Wayland as the display server.

Process host

For the host of the input method, basically there are two approaches that can be done, depending on the requirements of the system that we want to support, and we want to support both approach and can be easily switch between those.

In-process

This approach will bring the input method in the same process as the application. The memory consumed by input method is shared with the application. It also affects the startup time of the application.

Implementation details

• Instantiate the MIMPluginManager inside an input context plugin
• Have a widget to show the plugin UI, replacing the MIMApplication passthrough window
• Some tricks needed so the widget does not steal the focus of the text entry widget (which would cause the input method plugin UI to be hidden).

This approach would be feasible for these use cases:

• QtCreator support: developing Qt application will automatically use MeeGo Input Method when text entry is activated
• Symbian support: overriding Symbian's default input method and use MeeGo Input Method instead in Qt applications (might not work in legacy Avkon applications)
• single process Lighthouse/Wayland: The startup time and memory consumption are no longer relevant here as there would be a single instance of input method in a single process Lighthouse scenario.

D-Bus connection

When used in-process, even though if the platform supports GLib D-Bus API, there is no point of having the connection using D-Bus API. Here the MInputContext may need to be modified to do direct call to the input method plugin.

Out-of-process

This approach will still need the presence of compositor or be part of the compositor.

Implementation details

• Instantiate MIMPluginManager inside a Wayland compositor, preferably a QML based compositor.
• Have an option to use a QML element as the UI host of the plugin so total solution would be QML based widgets.

This approach would be feasible for multiprocess Lighthouse applications setup.

Hardware keyboard mapping

Internally Wayland is still using xkb, but having a dedicated interface to manage the hardware keyboard would make sense.