We released Maliit 0.80.7 on Friday. Over these last days, I am doubly proud about our project. Not only did the N9's virtual keyboard get astonishing reviews across the board, but what's even better: We managed to keep this software open-source. In our communities, there will always be those who focus too much on technical aspects. I remember the technical struggles we had even within MeeGo! But now we get feedback from real users who couldn't care less about what Qt or MeeGo Touch is, and to be honest, that's a refreshing change.

Being here at Qt's Developer Days 2011, it feels great to get such feedback directly, from first-time users of the Nokia N9. Especially the fine haptic feedback and the keyboard's accuracy gets noticed.

I also had the possibility to see a Japanese input method — running on the N9 and powered by Maliit. Seeing how well this plugin already integrates with the platform, I feel that our architecture yet again has been justified. I am looking forward to see more Maliit plugins, and more platforms using Maliit!

When mapping Qt/C++ API's to QML, or, to put it more precisely, making a Qt/C++ API available to QML, road bumps are to be expected. One such bump is the mapping of C++ enums.

If you happen to create enums inside a QObject, then it will be exported to QML via the Q_ENUMS helper:

SomeEnumsWrapper
    : public QObject
{
    Q_OBJECT
    Q_ENUMS(SomeState)
public:
    enum SomeState {
        BeginState,        // Remember that in QML, enum values must start
        IntermediateState, // with a capital letter!
        EndState
    };
};

You will still need to declare this class as an abstract type for QML to be able to use enums from it (put in your main function for example):

qmlRegisterUncreatableType<SomeEnumsWrapper>("com.mydomain.myproject", 1, 0,
                                             "SomeEnums", "This exports SomeState enums to QML");

Now in QML, the enums can be accessed as '''SomeEnums.BeginState'''. Note how the enum is accessed through the exported type name, not an instance.

But what if you've put your enums into a dedicated C++ namespace? Then the same mechanism can be used. Let's start with the namespace:

namespace SomeEnums {
    enum SomeState {
        BeginState,
        IntermediateState,
        EndState
    };
}

We can re-use the idea of wrapping enums in a QObject type, with one tiny change:

SomeEnumsWrapper
    : public QObject
{
    Q_OBJECT
    Q_ENUMS(SomeState)
public:
    enum SomeState {
        BeginState = SomeEnums::BeginState, // Keeps enum values in sync!
        IntermediateState = SomeEnums::IntermediateState,
        EndState = SomeEnums::EndState
    };
};

The process of forwarding all your enums through this mechanism can be tedious, but being able to use enums properly in QML properly will improve the readability and maintainability of your QML code.

For a fully working example check Maliit's Qt Quick support

... 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.

Today, we managed to get out the first release of Maliit as an independent project. As far as possible without API break, we started to use our own Maliit naming convention for installation paths, library names, etc.

During that cleanup, Jan Arne did a tremendous job improving our build infrastructure. Instead of Qt's .prf files, Maliit now uses pkg-config everywhere. Plugin developers don't have to think about install paths - they can simply read it from the .pc files, for instance:

pkg-config --variable pluginsdir maliit-plugins-0.80

The version number at the end indicates another nice improvement: versioned libraries and plugin interfaces, which means several Maliit versions can be installed in parallel (although you never want to run more than one server per session).

To install the Maliit framework into a custom directory (say, $HOME/install), simply use:

qmake -r M_IM_PREFIX=$HOME/install

Afterwards, set your PKG_CONFIG_PATH to $HOME/install/lib/pkgconfig and compile the Maliit plugins. Quite honestly, it has never been easier to develop input methods for Maliit than with this release.

I was attending the Qt Contributors' Summit 2011. During the key note, it was promised that everything is up for discussion so I took my chance to discuss about improving input methods support for Qt5.

After some initial discussions with Kristian Høgsberg (Wayland, of course) and Jørgen Lind (who works on Qt Lighhouse), I also addressed Wayland. It became clear that one needs some kind of input method interface directly in Wayland. Kristian immediately started with a small prototype, in order to explain better how a Wayland compositor can provide a much better window management policy than what we currently have with Maliit and X11.

I think the session itself was really successful. I was surprised at the strong interest in this topic.

It became apparent that we should do something about Qt's input context API. For instance, add more input methods hints, come up with a better interface that describes the focus widget, preedit handling, orientation support and so on.

Now we only need to agree on how to make it happen :-)

Jon spent a lot of time in the last weeks improving our documentation for Maliit. However, while documentation is good (and necessary), Jon thinks that examples are better. I can only agree with that.

I am planning to use Jon's example material for an input method workshop at one of the upcoming MeeGo Freedays (German only) here in Berlin, just to see how useful it is for newcomers.

Maliit starts to feel more and more like a real open-source project, and I am proud of that. Just compare our wiki from end of February with the current, information-packed version, or take a look at the steady traffic on our own mailing list (started only in March this year). Or perhaps just try googling it!

I am really happy to eventually see real contributions and input method plugins from others, which makes me think that we are on a good way.

But this is still only the beginning, and more interesting news will follow soon.

I was attending the MeeGo Spring Conference as an invited speaker, talking about Maliit - the MeeGo Input Methods - and how to develop custom input method plugins for it.

We had more people going to the talk in Dublin than to this one, but at least the slides and the recording are available online now.

The MeeGo Spring Conference in San Francisco was nice, perhaps not so much for the press folks (uninspiring key note, no product announcements). As a speaker, I was fortunate enough to receive sponsorship from the Linux Foundation (special thanks to Brian Warner for the unbureaucratic approach to this). I got to meet a lot of people face-to-face and the hallway track spawned interesting discussions, circling around questions such as:

• Why would 3rd parties pick up MeeGo if it comes with an unfinished and unpolished UX?
• Why would 3rd parties perceive the MeeGo Conference as the wrong place for product annoucements?
• Is the MeeGo community inherently hostile towards the Open Core model of MeeGo?
• Where is the place for commercial engines in MeeGo?
• Why is Nokia's Qt development generally not regarded as an active MeeGo contribution coming from Nokia? QML scene graph, anyone?
• Why does a company such as Intel, which does not see itself as a MeeGo vendor, come up with its own app store?

And, of course the poisonous:

• Is MeeGo dead?

(I am going to be mean and won't answer the questions for you, as I am too opionated here, sorry.)

Other than that, San Francisco was of course great. I also spend some time travelling through California; the country side is simply gorgeous.

This week I pushed a simple QML-based virtual keyboard to our MeeGo Keyboard repository. It's functional, but don't expect too much. This functionality will most likely never arrive in MeeGo 1.2, sorry folks.

I've never been happy with the conclusion in the influential blog post "Qt Graphics and Performance — The Cost of Convenience" by Gunnar Sletta: If you want performance, downgrade QGraphicsView to a mere canvas with a single QGraphicsItem. It defeats the whole purpose of decomposing the problem into many small QGraphicsItems and is therefore entirely counter-intuitive. One might be quick to ask what Qt Graphics View is good for (and one might find the answer here), but instead I would like to present an alternate solution to Gunnar's which reaches the same performance but embraces the very nature of Qt Graphics View.