As Maliit consists of several components that can be built in several different ways (and for several different platforms), we wanted to automate the build and tests of the different variations to ensure that we do not break any of them. This is especially important for variations which are not easy to test for the individual developers, like for instance Maliit on Qt 5.

The software chosen to help with this task was Buildbot. Getting an initial instance it up and running was very quick and pain-free, especially thanks to packages being easily available and the excellent documentation. The current setup now builds, tests and installs the two major components we have: Maliit Framework and Maliit (Reference) Plugins, in the most important build/config variations we have. A total of 12 individual build jobs, plus 2 meta-builds. The configuration for the instance can be found in the maliit-buildbot-configuration repository.

For security reasons the build-bot is not directly exposed to the Internet. Instead a script runs every 5 minutes to generate a static HTML website and publish on the public web-server: Maliit build-bot

Buildbot says: All green!

This gives us a minimal continuous integration system for Maliit, which for now will hopefully helps us avoid breakage. In the future, the usage of the build-bot might extend to include:

• Automating the release process
• Testing of merge-requests/patches before merging to master
• Automated integration/system testing, complementing the unit-tests
• Triggering external builders for packaging. OpenSUSE OBS, Maemo 5 Garage, etc.
• Automating certain aspects of bug-lifetime. Resolving when fix is committed, closing on release if pre-verified, etc

Maliit running on WeTab with Fedora 15, showing QML reference plugin and GTK+ application

Two implementations existed for Maliit GTK+ support. One was written by Javis Pedro as part of a Google Summer of Code project for MeeGo in 2010. His blog has several posts on the topic. The other implementation was maintained by Raymond Liu (Intel). This is the implementation shipped in Meego Netbook, and the one improved by Claudio Saavedra (Igalia) as part of the GTK+ on MeeGo project. It was also the only one that was updated to work with the DBus connection changes that was done quite some time ago, and supporting both GTK 2 and 3. For these reasons this was the implementation integrated into mainline Maliit.

Once the code was integrated, improvements soon followed. The application now correctly reconnects to server, and make install will automatically update the GTK+ input module cache on Ubuntu, thanks to Łukasz Zemczak (Canonical), and on Fedora. This means GTK+ application support will work out of the box, no twiddling needed.

While this is a huge step in the right direction, the GTK+ support is not as good as for Qt yet. Javis Pedros implementation has features that does not exist in mainline, so code/principles can hopefully be reused from there to implement these. This includes custom toolbars and attribute extensions, and content type hints for text entries. Other features looks hard to implement due to limitations/differences in the input context plugin architecture found in GTK+, and will probably need work in GTK+ itself to solve.

To make it simple to start developing an input method for Maliit, we have written a set of example plugins that can be used as a skeleton* for a new input method. There is one “Hello World” example showing the C++ interface, and one showing the newly added QML interface. The latest documentation for the framework in HTML format is also included, along with a simple test application. How to get started is documented on our wiki page: Go!

A very conventional example: An input method that allows you to input "Hello World"

A nice thing is that these examples are in our framework repository: built as part of the standard build, with simple tests run as part of our test-suite. This ensures that the examples stay up-to-date and working, something I find that step-by-step, code-and-talk tutorials in some documentation repository/directory typically do not.

If you want to look at real-life examples of plugins, check out the Meego Keyboard code (C++), the Meego Keyboard Quick code (QML), or foolegg from maemo.org’s cute-input-method code (QML with Pinjyin support!). Also make sure to check out Michael Hasselmanns talk at the Meego Spring 2011 Conference: Developing custom input methods for Meego.

If you hit any issues, contact us through one of our communication channels.

* Note that currently the license of the examples is LGPLv2 like the rest of the framework.

This initial video shows Maliit running in Gnome 3, and demonstrates some of the very basic features provided by Maliit and the standard keyboard shipped with it. The demo is done on a WeTab tablet running a standard Fedora 15 Beta, with the latest Maliit software installed. Jan Arne Petersen is working a bit on  Fedora packages, so hopefully it will soon be easy to install for those who are interested.

Some more info about the features shown in above video:

0. Theming. Using the theming support in the standard Maliit keyboard, it is easy to go from a mockup to ready implemented theming. This theme was based on the mockup from live.gnome.org (by Jakub Steiner I believe?) and done by Michael Hasselmann in a couple of hours. He also has a blogpost on how the theming system works.

1. Typing text.This is of course the number one feature of an on-screen keyboard. There are some essential best-practice and some tricks used in Maliit to be able to get really good reponse time and typing speeds. I hope we will have some blogposts about that soon.

Typing speed can be further enchanced by enabling multitouch support (not working out-of-the-box in Fedora due to missing support further down the stack), or by installing a prediction/correction engine. User feedback can be enchanced with audatory and tactile feedback (requires hardware and driver support obviously).

2. Different languages/layouts, and switching between them. Maliit comes with layouts for over 20 languages, tested and tweaked by usability experts. Latin, Cyrillic, Arabic and Chinese based scripts are covered. The layouts are defined by XML files, so one can easily change them if wanted.

For more of the features offered by Maliit framework and standard keyboard, see the wiki page. If you are interested in improving Maliit, or its integration in Gnome 3 or other GNU/Linux environment, join the irc channel or mailing list.

Next up; the importance and difficulties of input method integration on touch enabled devices.

The conference was held at the Aviva stadium, a huge sports stadium just outside Dublin center. Untraditional venue choice, but it was quite nice and the organization was very good.

The conference schedule was packed; 2 days with 5 parallel tracks and the third day done unconference style with some 7 parallel sessions (btw, all the talks are available online). Many of the technical talks I went to were a bit on the light side in my opinion, which is forgivable considering how new the whole Meego thing is (or maybe I just chose badly). However, the keynotes and some less-technical talks (and some discussions in the “hallway track”) gave me much better understanding of what Meego actually is and aims to be.  Which is arguably just as important.

The schedule was fairly packed in the evenings as well, with opening reception and  “Openismus conference dinner” at the closest pub the first day, party at the Guinness Storehouse the second and a Ireland-Norway friendly in football (which Norway won!) the third. In addition, the official conference hotel had a “hacking area” available 24-7, which was pretty popular.

To give Meego a little boost,  all the participants were given a Lenovo Ideapad S10-t3 tablet netbook/laptop. In exchange we had to install Meego Netbook Edition 1.1 on and promise to develop cool applications for. Lucky me also got a Nokia N900 so I can do development for that form-factor as well.

What is Meego? (my interpretation and some musing)

At least Intel seems to have a very clear vision of  Meego as an open operating system and software platform that will make it easy for people to deliver new and innovative products in the embedded/mobile/space.

Meego explicitly targets a broad range of device classes, from set-top boxes to in-vehicle-infotainment to handsets to netbooks, a very bold move. Personally, I think the key to succeeding in that aspect is to attract the vendors with expertise in each device class and have them drive development. The project has done a decent job at that so far with Intel, Linpus, et.c. for netbook, Nokia for handset, the GENIVI consortium for IVI and so on.

Another thing the Meego project explicitly supports is for vendors shipping devices to do customization. This is basically a prerequisite to be able to attract them at all (as they naturally want to differentiate their products), but brings additional challenges in delivering a consistent platform and brand. The compliance specification work presented at the conference leads me to believe that the project is on the right path here though.

As an application platform Meego is based around Qt (with Qt Quick). This is a decent platform, but what is most lacking in order to attract application developers is probably shiny, attractive devices, and people using them. Hopefully they will be here soon…

All in all, I like what I see. Time will show how well the project succeeds, there are certainly exciting times ahead!

One of the things I’ve done with that is to make a simple application, an image viewer called Imago. The code can be found at Gitorious. It is a bit different from typical Qt Quick applications as it is not a mobile application but rather targets the desktop. Thus I’m using standard desktop UI concepts like drop-down menues, and ordinary file-chosers.

Imago - single image view

Imago - "traditional" view

Imago - grid view

The lists can be “flicked” through using the pointer, or using the scroll wheel. Moving between the views that show multiple images and the single-image view has a small animation.

Implementation

In a Qt Quick application two languages and runtimes are involved; C++ and the declarative language that forms the basis of Qt Quick, QML. Qt supports bi-directional communication between the two using a number of metods.
In my case I chose to make a QObject class that  maintains all of the central state in the application. This includes things like what folder is currenty open, the images in that folder, which image is currently focused/selected. All these attributes are implemented as QObject properties, and are notifyiable (meaning they have an attached signal that you guarantee to emit each time the value changes). Exporting this object to QML then allows these properties to be used in property bindings, or for one to connect to the notification signals.
So in Imago QML is basically used as a “stupid” UI layer for the image view. Other things, like window title and drop-down menues are handed by the C++ side, but by using the signals and properties of the same object.

Writing a desktop application means that one cannot assume a fixed window size like people tend to do for mobile device applications. With setting the resize property of the QDeclarativeView (the widget that displays the QML stuff) to QDeclarativeView::SizeRootObjectToView and using anchor layouts throughout this is possible, but it took me a good while to get working properly. Mostly because the concepts are new, and most (all?) the examples in the documentation seem to neglect this aspect.

The grid and traditional view are actually implemented in different QML files (though the delegate for the images in the list is shared). I did this to test how having several UIs would be like, and for a simple application like this it works out just fine.

Where to now?

Imago right now is very simple,  and could benefit from some added features and some designer love. I also just found a bug in the traditional view that needs to be fixed. I have documented these things in the README file in case someone is interested. As I have moved my focus over to other projects, I probably wont be taking this application much further, at least not at this time.

glom-postgresql-setup lets you to create a database user, and set up the PostgreSQL configuration to accept connections from external IPs. The UI is just a dialog with two fields and two buttons, dead-simple indeed. For now the application requires to be launched with superuser privileges, but before we encourage use of this tool we will of course implement proper privilege escalation using PolicyKit.
It would also be nice to be able to install and start the PostgreSQL server as well, but currently that is not so easy to do in a cross-distro way. Hopefully packagekit and systemd will help solve that, eventually.

I asked for real art but as you can see, I did not get any.

The level of features supported is such that you will be able to preview OpenRaster documents created with applications like MyPaint, Drawpile, Nathive and GIMP, with the limitation that it will have a white background for transparent areas. The code can be found in qopenraster repository on gitorious (no tarballs), and the README file documents how to install as well as things that remain to be done.

The plug-in is basically a thin wrapper around libora, the OpenRaster reference library. libora takes care of parsing the OpenRaster document, reading out the layer data and rendering it into a single buffer. The rendering ability was added by me as part of this work, in addition to some other minor stuff. The Qt plug-in does RGBA to ARGB conversion and provides the QImageIOPlugin interface expected by Qt.

Doing this has also exposed several limitations and not-so-nice things in libora that should/needs to be improved. I’ve updated libora’s README file to reflect this.

*Assuming the Qt application actually uses QImage in a straight-forward way. The KDE image viewer Gwenview does not seem to use QImage directly, so you will not automatically get support there by installing the plug-in (. I fear that other KDE applications might be the same, though I was not able to test Digikam. If anyone has a suggestion for a Qt based image viewer that works sanely in this area, don’t hesitate to leave a comment.

PS: I have an almost-working gdk-pixbuf module as well, will push that to gitorious soon.

In the per-conference day with training sessions I attended the Qt Essentials track, which was more or less as expected. Glad I read a full Qt book beforehand, it would have been challenging to keep up with the shear amount of information without it.
The keynotes I attended on the second day were not particularly exciting: no major announcements nor insights were given. The technical talks on the other hand were filled with goodies. The talks by Jens Bache-Wiig and Roberto Raggi on Qt Quick were especially good.*

The talks definitely made me want to try Qt Quick for doing user interfaces for small-form factor devices, especially because it allows for very rapid prototyping and iterations when developing. The current lack of widgets and traditional layouts probably limits its usefulness for typical desktop application with more complex user interfaces though. There is nothing that helps you achieve a native look and feel either, but the Qt Components project is aiming to bridge those gaps.
I also suspect that the declarative and dynamic nature of QML poses several new challenges for developers, especially for those that are mostly used to traditional Qt programming with C++. I’m especially concerned that there was no way to visualize or do static checking on the property-bindings that are so central in QML. Very curious as to how that plays out in practice.

*I’m told the talks will be online after the Qt Developer Days event in San Fransisco is over.

Qt projects you said?

Going forward I’ll be doing some projects with Qt, in the same way I have done with GTK. My first project has already started: implementing viewer-class OpenRaster support for Qt. This means that applications using Qt and QImage will soon be able to display fully-rendered OpenRaster images!
Development of the Qt integration happens in the repository on gitorious, and the libora modifications currently lives in my personal clone. It will be pushed to mainline as soon as I have more-or-less settled on the API, and done a basic implementation. Using libora for all the OpenRaster specific stuff is being a bit more painful than expected, but it is the right thing to do as it means that other consumers benefits as well. Like a potential GdkPixbuf plugin or applications not using Qt or GTK. I’ll write more once it reaches a useful state.

After that is done I will probably do something with more UI, like a proper application. Hopefully I will get to toss Qt Quick into the mix as well. I’ve got an idea that I think would be a nice fit, so we’ll see.