Maliit/Ideas/Supporting Non X11 Platforms

Revision as of 15:47, 17 June 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. https://meego.gitorious.org/~krh/meego-ux/krhs-meego-ux-daemon can be used as a reference.

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. In there, everything is a QSceneGraphItem and managed by the compositor. Furthermore, we can't use QtQuick 1.0 and nor the QGraphicsView based plugins inside this world.

First approach

This approach is to display input method as one of the client window of the compositor.

• 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. The MIMPluginManager then exposed to QML world as QSceneGraphItem as "InputMethod".
• In the compositor's main QML file, Maliit needs to be included, eg. something like:

import QtQuick 2.0
import Maliit 1.0  // 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.

Second approach

This approach is to display input method graphics into an item specified by the application. The application still need to include an item like this:

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

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

Then, the compositor need to be aware of this special item, and blit the graphics of the input method plugin into the area and handle the input events accordingly. This may need a quite an effort in the compositor side.

Both approaches would be feasible for multiprocess Lighthouse applications setup. Modification to MImPluginManager is quite easy and minimal, removing the X11-tied classes out from the project files.

Input Context

The application may be easier to use a declarative version of MInputContext instead of using the normal QInputContext interface, as they are not QWidget nor QGraphicsView which is now heavily used in MInputContext.

Hardware keyboard mapping

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