Openismus gave me the opportunity to check how good or bad Maliit works together with Plasma Active. As I've never installed Maliit nor Plasma Active until now I expected some pitfalls, but in the end I got both of them running on a WeTab tablet:
Most Planet KDE readers are of course familiar with Plasma Active, but what is Maliit?
Maliit
Providing a virtual keyboard seems to be straight forward in the first sight, but it is very challenging if things like predictive input, error-correction, cut/copy/paste, multitouch, context-sensitivity or languages like Chinese and Arabic should be supported.
Current State
The combination of Plasma Active and Maliit works together better than I expected initially: Focusing an input field automatically pops up the Maliit keyboard and entering a key results in showing the output without delay on the WeTab tablet. This sounds self-evident, but the performance is very critical for a virtual keyboard: Even a minor delay after touching the device gets noticed by users - the acceptable delay seems to be a lot lower than the usual "keep it below 300 ms and it will be perceived as fast" user interface objective.
At the moment there are at least two open issues that need to get fixed in Maliit:
- When entering a key the 'key magnifiers' (= the orange 't' in the first screenshot) don't disappear. The issue is tracked on the Maliit bug tracker and investigations are ongoing.
- Currently Maliit requires compositing for providing the virtual keyboard as overlay.
Installation
I've installed Plasma Active and Maliit from the sources on the master-branch to be sure being on track with the latest state of both frameworks. For Plasma Active the installation guide and the development guide are sufficient for building Plasma Active. I've added a few notes to the Maliit on Plasma wiki to document the approach I've taken.
Installing Maliit is straight forward. On the first screenshot above word prediction is enabled. For this Presage is required, one pending merge-request must be used and qmake must be called with CONFIG+=enable-presage
The progress of integrating Maliit into Plasma Active is tracked at https://bugs.maliit.org/show_bug.cgi?id=51 - I cannot judge the final outcome of this, but I think from a technical point of view it is a benefit for both frameworks if they are interacting well. Whether Maliit might be a candidate for being the default input method for Plasma Active also involves some non-technical topics like the general maintenance of Maliit and whether there are enough resources to make the integration with Plasma Active really perfect. We'll see :-)
7 comments:
Hi Peter,
this sounds really interesting. There was a question about virtual keyboards on the kde accessibility mailing list a while ago.
How hard would it be to get Maliit running as keyboard for regular KDE? I guess it's not too much work?
Awesome! :)
One question, does input widget relocation work?
@Frederik:
> How hard would it be to get Maliit
> running as keyboard for regular
> KDE? I guess it's not too much work?
That's what I tried first and it is quite simple. A
export QT_IM_MODULE=Maliit
tells Qt about the input-context. After starting maliit with:
maliit-server -software -bypass-wm-hint
you can use Maliit with your regular KDE desktop :-)
A more detailed description is in the README from git@gitorious.org:maliit/maliit-framework.git
@sebas:
> One question, does input widget
> relocation work?
It at least worked when I tried Maliit with the active-browser ;-)
I'll ping my colleagues at Openismus to give you a more reliable answer - corresponding to https://wiki.maliit.org/Documentation/Examples it should be integrated but no examples seem to be available yet.
Surprising, but a good sign :)
The webbrowser has most of its content in a Flickable, so it probably won't work with apps that have not, but it's a very good start already.
That input widget relocation works is indeed a bit surprising: I wonder where the browser gets information about which areas are being covered by the IM.
Anyways, Maliit has everything needed to make IM widget relocation work. For Qt4, we ship a libmaliit extension library, where one can get information about the area covered by the input method.
Signal "areaChanged(QRect)" on Maliit::InputMethod::instance()
So ideally this will be hooked up in the PA toolkit for best integration with Maliit.
For Qt5 we managed to get this in as part of the standard input method API, so no linking against a Maliit specific lib is necessary there.
And yes, this is something we should definitely have in our examples as it is perhaps one of the most common integration points for toolkits.
Post a Comment