Thoughts 'n Stuff

Maliit as your remote control (video)

There is seemingly a trend (in ideas) to use your mobile device as a remote control for stationary devices such as your TV.

We thought that experimental support for remote text input should be easy to add to Maliit, as it already comes with a server-client architecture. As soon as client and server can run on different host machines, we’d have network transparency and it should basically just work. Luckily, we use D-Bus as our IPC, and it turns out that D-Bus understands remote host addresses. If you check the README in maliit-framework you will recognize that – with the latest release (0.90.0) – it only takes an additional environment variable, MALIIT_SERVER_ADDRESS, to connect a client (that is, an application that uses the Maliit input context) to the input method server. The scary part is perhaps that one has to disable D-Bus authentication. Therefore it's a good idea to only use this inside a trusted network.

Jon created a video which demonstrates the new feature in a better way, using a laptop that is connected to a projector as a TV replacement. The great thing about this feature is that it requires no changes to the applications, nor to the Maliit input method plug-ins, it’s the framework that handles this internally (or not so internally, now that Qt 5 turned our D-Bus API into a public one).

However, to make Maliit truly useful as a remote control, at least two additional features are required:

• Have a proxy text editor widget on mobile device that allows text interactions such as copy and paste, cursor positioning and rich text formatting.
• Emulate and transmit mouse or touch events, possibly through a dedicated touch area on the touch screen of the mobile device.

The second feature requires an extension to the Maliit protocol, whereas the first is already filed as bug MALIIT#84. After that, I could use my N9 (or my N900, as Maliit also runs there) to remote control my Gnome or Ubuntu Unity desktop, which would work perfectly for my movie watching habits. Kudos goes to Krzesimir and Jon for their work on this feature.

Into the Wild

We kicked off the new 0.81 release series together with a nice announcement: We have our own bugtracker now!

This means that Maliit has a near complete project infrastructure, all available under *.maliit.org, and all that thanks to Karsten, the always professional and very experienced hostmaster here at Openismus.

There is one more thing that we need (as demonstrated by me when I made my first broken release), and that's a simple build bot setup for continuous integration. Right now, we still rely on Nokia's infrastructure. I am confident that buildbot will fit all of our requirements, as long as it is trivial to maintain.

I am also happy that we improved our documentation significantly, thanks to Dave. He translated the important documentation bits into proper English and made it more accessible, demonstrating his doxygen skills. As a bonus, he also updated the project's README files, something we had neglected for a long time.

Future development

Regarding the Maliit development, I think we have simplified things a lot. D-Bus activation for the Maliit server (which finally means one server instance per user session) and the new support for plain QML plugins makes it almost trivial to get started with Maliit. We also let go of the critically acclaimed MeeGo Keyboard in Maliit upstream, which made me a bit sad of course.

Still, it probably was the right decision: MeeGo Keyboard is heavily fine-tuned for Nokia's N9 and it has some dependencies that are hard to satisfy outside of Harmattan. Over time, with ever changing requirements, the code has naturally evolved into a rather complex design. The result, however, is a very polished product, and ultimately, that's the only thing that matters (even though many opensource developers will disagree, strangely enough). Everyone in the team is proud of what we have achieved.

At the same time, I can understand how new contributors will be put off by all the complexity. So Maliit upstream will instead focus on the very basic but almost trivial to build Maliit Keyboard. For new contributors, that's a good thing. For us, it means the possibility to fix shortcomings in the plugin API. This is important, as one of our main goals has always been to enable others to write great input method plugins for Maliit, which will then run on any platform that Maliit supports. The Swype VKB plugin and the Japanese VKB plugin for example both demonstrate that we are on a good way, but I think we can do better.

Maliit itself still needs a good reference plugin, of course, even if only as a showcase (though I want it to be more). All this doesn't mean that MeeGo Keyboard goes away; its development will continue in the MeeGo Touch repositories, just as before (effectively degraded as just another Maliit plugin). But what we can take over, hopefully, is our experience when it comes to creating one of the best virtual keyboards currently available.

Qt Quick best practices: Using Components

The next article in the series about Qt Quick best practices has been published (but don't miss out the other one about property bindings). This time, I talked about Components, and how they can help to keep your QML code clean and maintainable. The team behind the N9 Developer blog has been a great help to me, especially Ville Lavonious and Matti Airas. I am also thankful for the additional input (and proof reading!) from Jon Nordby and Sauli Kauppi. Thanks guys!

Miniature 0.5 "London 1851" released

From the release notes: "Miniature now supports different languages thanks to a determined community of translators. Thank you for your effort! This is why we are dedicating this release to the first international chess tournament, celebrated in London on 1851.

Miniature 0.5 is being released for MeeGo Harmattan (Nokia N9 & N950) and Maemo (Nokia N900). Thanks to everybody involved in the initial Maemo attempts and the experimental version that was made available after the Miniature 0.4 release."

We also improved usability, compared to the previous release, but there's still a ton of work left.

A bit of history

I started working on Miniature – a chess client for freechess.org – in November 2009, after reading the Call for Contributors. Even though we had a pretty cool P2P feature (based on Telepathy and developed mostly by Dariusz Mikulski), it never quite reached the original goal: playing chess online. Back then I was learning how to create UI's with Qt Graphics View, which was all the rage at the time. Well, we now know that writing real UI's with that technology is a major PITA, but for my pet project, it was just too much. I got lost in the struggle.

For the next 18 months, Miniature was basically dead. Another failed project that started so promising. Quim did not want to give up though. After the N9 announcement, he launched a second Call for Contributors.

Perhaps I responded to his mail because I was embarrased at the idea of people wasting time trying to salvage the working parts of Miniature; there simply wasn't much to salvage! So I started again, this time with a very clear goal: online chess, and online chess only. Let others create the actual UI and whatnot. Focusing on one prominent feature and not having to worry about the UI worked well for me, even though I had to iterate over some architecture ideas until I felt comfortable. Quim in the meantime started to prototype the UI with QML. It was impressive to see his results, a level of polish I could have never achieved with my Qt Graphics View approach. At some point the backend was good enough to be sewn together with the frontend and suddenly we had achieved where I failed before: A touch enabled chess client for the N9 that can play chess online.

Having my own useful application available on the N9, published through OVI store, means a lot to me. I hope others will enjoy Miniature as much as we enjoyed re-creating it the second time around.

Using MeeGo Keyboard from git on your Nokia N9

Usually AEGIS, the N9's security framework, protects system packages from being replaced. As such, files belonging to a system package can't be overwritten. And that's definitely a good thing, because otherwise each download from OVI store would put the user at a considerable risk.

Maliit is such a system package, but its flexible architecture allows for a creative way to replace the MeeGo Keyboard with a more recent version. This can be useful if you want to testdrive new features and to … nah whom am I kidding, it's purely for fun!

Be warned though, the following hack requires you to enable developer mode on your N9. Don't ever activate it unless you're absolutely sure what you're doing to your N9. It would be unforgivable to brick this beauty because of some misguided hack the planet attitude.

First we need to find a MeeGo Keyboard tag that will be compatible with the installed Maliit framework version on your device. Check that the output of

$ apt-cache showpkg meego-keyboard

matches the dependencies mentioned in the tag's Debian control file and the packages installed in your scratchbox ARMEL target.

Apply the community patch on top of the chosen tag. It renames the package to meego-keyboard-community and only installs the plug-in's .so file, together with a renamed CSS file (libmeegotouch requires that CSS file names match with library names).

This mean that we won't uninstall the regular package, as we still depend on most the other files that meego-keyboard installs.

Now build the Debian package. Copy it over and login to the device, then gain root access via devel-su. It's recommended to make a backup of /usr/lib/meego-im-plugins before installing the package.

After installing libmeego-keyboard-community, remove libmeego-keyboard.so from /usr/lib/meego-im-plugins, to avoid in-fights between the two plug-ins. Use

$ gconftool-2 -s /meegotouch/inputmethods/onscreen/enabled -t list --list-type string [libmeego-keyboard-community.so, en_gb.xml]
$ gconftool-2 -s /meegotouch/inputmethods/onscreen/active -t list --list-type string [libmeego-keyboard-community.so, en_gb.xml]

to activate the community plug-in. The language settings applets will most likely get confused, so be prepared that enabling new language layouts might only work directly via GConf from now on.

Gain user access and kill meego-im-uiserver. It should now load the new community plug-in. If you want to get the original MeeGo Keyboard back, uninstall the community package and copy the .so back from your backup. Alternately, you can try to reinstall it:

$ apt-get install --reinstall meego-keyboard

Have fun!

Best practices in using Qt Quick

I am writing a series about best practices in using Qt Quick. It will be published on the official N9 Developer blog. The introduction and first article have already appeared. Your feedback on that series is very much welcomed.

So there are people who say that Nokia's N9 isn't MeeGo …

… and those people are right, if we followed the MeeGo Compliance Spec to the letter.

But at the same time, Nokia's N9 is one of those devices that the MeeGo community has always been waiting for.

If "This is not MeeGo!" is the only thing that comes to your mind whilst reading about all the N9 excitement then you still haven't realized MeeGo's biggest problem: No. Compelling. Devices. And if - at the same time - you are one of the MeeGo project leaders, then you should do yourself and everyone else involved with MeeGo a favor and simply resign.

We need more visionary leaders than you.