On Friday I pushed 194 commits to the Maliit Plugins repository, adding new features, bugfixes, cleanups and tests to the Maliit Keyboard. This is some of the work Openismus has done for Canonical over the last few months which we are now allowed to upstream. This includes hard work by Michael Hasselmann, Krzesimir Nowak, Jan Arne Petersen and Jon Nordby.
Our work on the underlying Maliit Framework for Canonical was published upstream as we did it. We believe we’ll be able to upstream more of our Maliit Plugins work in the future.
Versions of these Maliit Plugins commits were published a few days ago in the Ubuntu Phablet project’s maliit-plugins Launchpad/Bazaar repository. It also contains commits (not by us) on maliit-plugins’ Nemo Keyboard, mostly for integration with the Ubuntu Touch platform (and its use of Android’s Surface Flinger). The recent Ubuntu Touch preview is using a version of that Nemo Keyboard, though we believe that’s meant as a temporary solution. A properly integrated Maliit Keyboard should behave significantly better.
Anyway, these commits add these features to the Maliit Keyboard:
- Auto-capitalization.
- Styling, such as a black underline for the current word and a red underline for a word with an error, though its up to the toolkit exactly how it shows this.
- Word prediction, error correction, etc are now available when editing previously-entered words, instead of just the next word, taking into account the surrounding words.
- Users can add words to the dictionary with a long press on the space key.
- More settings to enable/disable auto-capitalization, auto-correction, word prediction, error correction, audio feedback and whether the word ribbon should be disabled in portrait mode.
- Applications can specify text and icons for actions keys, such as Done, Go, Login, etc.
- Keyboard themes can now specify fonts.
The maliit-plugins NEWS file gives more details.
Many of these features were already in the old MeeGo Keyboard (used by the Nokia N9) which had to be dropped last year because of its libmeegotouch dependency and its need for proprietary plugins to achieve these features.
We hope to have all this in an official Maliit release soon.
Would it be possible (from a technical stand point) to do a release of a new mailiit keyboard for the n9 with all these features/fixes?
thanks
Well yes, it would be possible but would take considerable effort. Someone would need to fund that. And what’s the point anyway? The MeeGo Keyboard on the N9 is still superior to Maliit Keyboard, if one only considers the user experience. The advantage Maliit Keyboard *might* have is the word ribbon UI.
Hm, I should have clarified why I can make the claim that MeeGo Keyboard > Maliit Keyboard: I did the initial rewrite of MeeGo Keyboard to what is now known as Maliit Keyboard in Dec 2011. Since then, we tried to slowly add all the great features of MeeGo Keyboard back, but it’s tough to replicate the work of a team with 10+ people, who worked on MeeGo Keyboard for 3 years. We are only a team of3 people here at Openismus doing the actual work on Maliit Keyboard. And we cannot spend as much time on it as we would like to. Such is the life of consultants.
In contrast, nearly 200 commits to Maliit Keyboard is a lot for us in the current state. We used to have 200 commits a month when MeeGo Keyboard development peaked. And yet we will need to keep finding sponsors for our project so that we finally get to a point where Maliit can be run on any Linux-powered mobile or embedded device, with a user experience that is comparable (or better!) to MeeGo Keyboard.
I hope that now that Maliit is used on more and more platforms, we will also get more contributors to help with the difficult parts. Or perhaps just help with documentation and some bugfixing.
Good work, glad to see it upstreamed. Congrats!Â
Hi All,
Actually my actual aim is to install the Maliit Virtual Keyboard in my PDA Root file system.
As per the steps and instructions i have to install Qt4/Qt5 in the Target RFS and then download, build and install the Maliit Framework and Maliit Plugin by qmake, make, make install
But now I am trying to build and install the Maliit Virtual Keyboard in Ubuntu 12.04
I downlaoded the Framework and plugin from
git clone git://gitorious.org/maliit/maliit-framework.git
git clone git://gitorious.org/maliit/maliit-plugins.git
Since we can install the maliit-plugin only after installing the maliit-framework. So i tried to build the maliit-framework at first
Error 1
**Tip: Run qmake HELP=1 for a list of all supported build options
Project ERROR: Qt 5 is required. For the Qt 4 input context see maliit-inputcontext-qt4. For a Qt 4 Maliit please use the 0.81 or 0.94-qt4 branches/release series instead**
Since i have Qt 4.8.4 i downloaded maliit-framework-0.81.4 which supports 4.8.4. In that also i got
**Tip: Run qmake HELP=1 for a list of all supported build options
Project ERROR: Qt4 input context requires Qt Glib support**
I tried to build Qt with glib support by
./configure -embedded arm -xplatform qws/linux-arm-g++ -qt-kbd-linuxinput -qt-mouse-tslib -webkit -dbus -glib -opensource -verbose -R /usr/local/tslib/lib/
i got
**Glib disabled.
Glib support cannot be enabled due to functionality tests!**
I tried for three days to solve this, But i could not
I tried to build the same source with qt-5 i got
**”Could not find dbus-glib-1 dbus-1 gconf-2.0″**
i installed Qt with dbus-1. But how can i give “dbus-glib-1,gconf-2.0” support in Qt
I am struggling in build step itself. Please help me to fix that.
Regards,
Vignesh
You posted the same text to the mailing list at the same time. Let’s deal with it there.
I actually use my Ubuntu phone mostly in Landscape mode and Windowed (default is staged). The problem I often face is that the onscreen keyboard taking up big portion of the bottom of the screen covers some of the window content over which it shows.
I wonder how difficult would it be, to actually include a transparency setting in the keyboard?
If you can partially see through then having the keyboard overlap your window still is fine. I imagine a simple transparency level that user can set to his/her own liking shouldn’t be a huge work for you the developers?
An even better, but with more work, as it would include masking, would be if the keys of the keyboard were completely transparent, and only key frames (the outer borders of each key rectangle) as well as the actual letters/symbols were opaque. This would allow a see-through as well.
Since maliit osk is said to support templates, perhaps these second approach could be addressed with a template?
Either way, it could potentially be a huge easing on using the osk in some user scenarios.
A concept:
http://api.sound.com.tw/dev/kris/maliit-concept.jpg