2012
03.24

The standard way of deploying Maliit is to have a single maliit-server instance (per user session), hosting the actual input method (virtual keyboard, handwriting). Applications then communicate with the server (and by extension, the IM) through an IPC.

This allows for a single instance of Maliit to serve all applications, which is memory efficient and robust. A crash in a Maliit IM plugin cannot take down the application and risk loss of significant user data. The disadvantage is the increased system complexity (a separate server process needs to be running at all times*) and requiring compositing of the application and input method windows. The latter can be quite challenging to do in a well-performing way on low-powered mobile/embedded devices. See Jans blogpost for how we handled that on the Nokia N9.

* By default we make use of DBus autostarting, of course.

Application-hosted Maliit

To make Maliit more suitable for systems where only a single application runs (embedded) or compositing performance is not good enough, we now also allow Maliit to be “application-hosted”: the Maliit server and input method plugins lives in the application process, not a separate server process. Enabling this feature has been a long running task of mine: All the code in input-context and server was made transport independent, a direct transport (no IPC) was introduced, and setting up the server for a given configuration (X11, QPA, app-hosted) was simplified. Other motivations for this work include being able to run the server and IM plugin easily for automated end-to-end system or acceptance testing, or just to easily start the server with a given IM plugin loaded for quick manual testing during development (see Michaels merge request).

An example application exists as part of the Maliit SDK that demonstrates the feature: maliit-exampleapp-embedded

Maliit running in application-hosted mode: The Maliit Server and input method plugin is embedded in the application instead of running in a standalone server process.

This works by having a special input-context “MaliitDirect” which instead of connecting to the server over DBus, creates the server and a direct connection. As when running standalone the server will instantiate and manage the necessary input method plug-ins.

Because the IM does not have its own window in this configuration, the application is responsible for retrieving the IM widget from the server, and re-parenting it into the appropriate place in the widget hierarchy. For all other purposes the application uses the same interface as if the IM was hosted remotely, making sure the abstraction is not broken and that one can easily use the application with Maliit deployed in different configuration.

This feature currently works with Qt4 applications, and is in Maliit since the latest release (0.90.0). One issue is that with the current input method API, the plugin assumes a fullscreen window; overlays extending the base area of the IM will be clipped and size needs to be overridden. This is something we are fixing in the new improved API.

Compositor-hosted Maliit

Another approach to make rendering perform better is to host the input method in the process responsible for the compositing. This also reduces the number or processes involved in rendering/compositing, and the associated overhead. This could be a X11 compositing window manager (like KWin or mcompositor), but a more realistic use-case is a Wayland compositor (for instance based on QtCompositor).

The API allows the consumer to inject an class instance for the configuration dependent logic, allowing to integrate the Maliit server with the logic in the rest of the compositor. Applications will use the normal “Maliit” inputcontext and communicate to the server through an IPC like DBus.

After the work with application-hosted Maliit, this feature was completed by making the server and connection libraries available as public API. The API is available in the latest  Maliit release (0.90.0), but is considered unstable until Maliit hits the 1.0 mark.

 

 

 

 

7 comments so far

Add Your Comment
  1. This is very interesting stuff. One thing I’m dreaming of, is the ability to use my phone as a wireless input device for my computer, for instance using bluetooth. A smartphone should be a very nice wireless touchpad, for instance.

    From your description, it sounds like Maliit could be suitable for that kind of use?

  2. You mean like we prototype here? ;) http://mikhas.posterous.com/maliit-as-your-remote-control-video

  3. Haha! Yes, that sounds fantastic! Great work :)

  4. what’s suggestion to using Maliit with QML run with QWS ? MaliitDirect or Maliit server embeded ?

  5. Hi Aaron. The maliit-discuss mailing list is probably a better place for this question than here: http://lists.maliit.org/listinfo.cgi/maliit-discuss-maliit.org
    In general I’d say to use Maliit as a standalone server/process unless there are special reasons to do otherwise.

  6. Hi Jon. I am trying to build the maliit-framework-0.99. It shows QWindow as no such file error and I tried adding QtGui to it as #include but still I get the same error. And I have Qt5 installed in Ubuntu 12.04. All I can guess its an environment problem but have no idea what it is!? Can you help me?

  7. Hi Xavier,
    I am not working actively on Maliit anymore, so this question should go to the Maliit mailing list or on the #maliit irc channel on Freenode. http://lists.maliit.org/listinfo.cgi/maliit-discuss-maliit.org
    If you ask the question there, make sure to include the full build log, including the command(s) you used. This makes it much easier to help solve the problem.

    But make sure that you are building with qmake from your Qt5 installation. It might be called something like “qmake-qt5″, and/or it may not be on your PATH so you may need to add it.