I recently pushed the Maliit team here at Openismusto tidy up the website, to make the current status clearer. Here is a summary:
Maliit is the only open-source input system that offers the features real products need, allowing on-screen keyboards for all the world’s languages. It is mature but it needs more work. This is the right project at the right time for various desktop projects to work together instead of having separate hacks that don’t please users.
Everybody loves the virtual keyboard on the N9, which Openismus worked on. That is the Meego Keyboard, which is built on the Maliit framework. It performs. It’s largely open-source, but it is fine-tuned for the N9′s MeeGo 1.2 Harmattan. It has an unfortunate dependency on libmeegotouch, which few developers love.
The newer Maliit Keyboard does not depend on libmeegotouch, though it does depend on Qt and QML. With enough effort, the Maliit Keyboard could be as good as the MeeGo Keyboard.
The underlying Maliit framework API has been thoroughly tested and iterated by these keyboards and by other input methods, both open source and proprietary. It has had many contributors, has gained many regression tests, and is run by people who care deeply about quality.
Note that Maliit is not trying to be an on-screen keyboard for accessibility.
GNOME
We’d like GNOME to allow use of Maliit so people are not forced to use the current Caribou keyboard that only works with GTK+ applications and doesn’t offer features such as CJK or word prediction. We know that GNOME doesn’t want a hard Qt dependency. Of course that would be silly. We do want cross-platform compatibility. We also think that this is a large problem space that GNOME cannot tackle alone.
That would need gnome-shell (or its St toolkit) to support GtkIMContext as Maliit uses it. However, the gnome-shell developers currently feel that any on-screen keyboard (or input method UI, I think) must be part of gnome-shell’s own source code, and can’t be a separate process. Even if caribou could be made to work with non-GTK+ applications, a gnome-shell dependency is an even bigger block to cross-desktop adoption than Qt. So I really hope that this hard problem can be solved, though I do recognize that it’s hard.
The IBus implementation in gnome-shell seems to be hitting several similar issues (1, 2, 3), impacting CJK users even without a virtual keyboard. When they are fixed, maybe Maliit will work better. Note that, though Fedora has replaced SCIM with IBus, neither are really an issue for the on-screen keyboard, because IBus doesn’t let you show windows such as keyboards. However, the non-UI engines in the IBus plugins could (and probably should) be used in Maliit plugins.
I have some more notes about the current gnome-shell virtual keyboard here.
Unity (Ubuntu)
We’d like Ubuntu to use Maliit. We don’t know of any problems with that now, though I guess this depends on the GtkIMContext support in Unity’s nux toolkit library. We will do some tests on the WeTab soon.
Update: We published some Maliit packages for Ubuntu Oneiric in our PPA and we were pleased to find that nux seems to support GtkIMContext so you can, for instance, use the Maliit keyboard in the Dash’s search field. There are a few problems (1, 2, 3) but they seem fixable. There are also some generic GTK+ problems, but these are not blocked by anything fundamental in Unity.
Ubuntu currently ships Onboard, though that’s apparently just for accessibility.
KDE and Qt
We’d like KDE to use Maliit for their tablet efforts. The Maliit keyboards work today in Qt and KDE applications, though I don’t know if that means that they work in Plasma too. They have a Plasma keyboard (source code) already, and there seems to be interest in using Maliit instead of, or as a base for that. That would give it features that it apparently lacks, while also sharing the maintenance workload.
Source Murray’s Blog
