Maliit/Ideas/Supporting Non X11 Platforms

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. https://meego.gitorious.org/~krh/meego-ux/krhs-meego-ux-daemon can be used as a reference.

Contents 1 Process host 1.1 In-process 1.1.1 Implementation details 1.1.1.1 D-Bus connection 1.2 Out-of-process 1.2.1 Implementation details 2 Hardware keyboard mapping

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

The details here assume that QtQuick 2's QML based compositor would be implemented. And here, we can't use QtQuick 1.0 and possibly also the QGraphicsView based plugins.

• Instantiate MIMPluginManager inside a Wayland compositor by using a normal QML plugin infrastructure. So here, the MIMPluginManager needs to be possible to be recompiled as a QDeclarativeExtensionPlugin.
• In the compositor's main QML file, Maliit needs to be included, eg. something like:

import QtQuick 2.0
import Maliit   // Import Maliit's plugin manager

...
InputMethod {
   id: inputMethod
   anchors {
      fill: parent
   }
}
...

• The QML needs to be crafted so the InputMethod needs to be on top of everything which needs input method.
• MIMPluginManager would still need to be responsible to insert the plugin's UI into the scene by just reparenting the plugin's UI into the inputMethod object there.

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.