MyPaint on Meego?

When I got back from the Meego conference, I tried building MyPaint on the Ideapad I got (which runs Meego Netbook 1.1).

I was pleasantly surprised to find pygtk in the core repositories.  numpy on the other hand was missing but that was easy to build from source. Buut, it seems that pygtk is built without numeric support, making MyPaint unusable; numeric support is used to get access to the pixels in pygtk pixbufs, which we need for several central things.
I have of course filed a bug for this so hopefully it will be resolved soon. If not I will have to provide alternative pygtk packages using the community OBS. In any case, expect it to be working soon.

I also hope to adapt MyPaint’s UI to the handset and netbook/tablet form factor, but this is only talk so far.

Meego Conference 2010

Like most of my colleagues at Openismus I was present at the first Meego conference in Dublin. As usual, I’m probably the last to blog about it. See for instance Friedrich’s post, Andre’s post or Chris’ very detailed post.

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!

Playing with Qt Quick; Imago

In learning Qt, I of course needed to get some experience with the newest and shiniest bits of Qt: Qt Quick.

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 - single image view

Imago - "traditional" view

Imago - "traditional" view

Imago - grid 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

Glom is an application that lets you design database systems, including user interface. It can be run as an ordinary application, and will set up and run a the database server for you automatically. But if you want to set up a shared instance, where several users connect with Glom to the same database, you typically want your database server on a dedicated server. And this can be a bit tricky to set up. So, glom-postgresql-setup was born; A dead-simple utility application to set up a PostgreSQL server for use with Glom. Like Glom, it is written in C++ using Gtkmm.

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.

Image preview support for OpenRaster in Qt working

While learning Qt here at Openismus I’ve written a basic, working plug-in for Qt that adds support for the OpenRaster file format*. Here is my Qt-based test application demoing this functionality by showing some awesome multi-layered abstract test art made by yours truly using Krita:

I asked for real art, but I did not get any

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.

First stable releases of misc. OpenRaster stuff

Better late than never (links go to the announcements):

Packages for Arch Linux is of course available in AUR. I might also make some simple .deb and .rpm packages for this, users should not have to wait until spring to get easy-to-install support in their distribution.

The OpenRaster development tools (oratools), the reference library (libora) and qt/gdk support needs more love before we can tag 0.1.0 but hopefully it will be soon.

Back from Qt Dev Days, first Qt projects

I’ve actually been back close to a week now, but never mind that…

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.

Proprietary platforms, free software and contributors

While I do not believe that killer applications exist, I do like to think that free and open source software applications adds value to the platform it supports, and its users. For small applications it might not be much, but still non-zero.
Personally, I do not particularly want to add value to proprietary platforms. I do not use them, nor want to “endorse” them. This is especially so if it means giving less to free platforms or software: I would rather spend my time on developing new features and fixing bugs in my favorite free software applications than to spend it on packaging and support for Windows, for example.

But at the same time I want to add value to free software as a whole and I recognize that getting the  software out to the user is fundamental. And that proprietary platforms like Microsoft Windows and Mac OS X have a ten to hundred times bigger user-base than free platforms like GNU/Linux. So time spent there would potentially be worth a lot, right? Yet I do not really want to do it, and I think that many existing free software contributors feel the same…

It is paradoxical that Windows and OSX represents the largest user-bases, often also for free and open source software, yet one of the smallest contributor-bases. How can this be fixed? How can we get more of the people that seemingly care about free and open source software on proprietary platforms to actually contribute?

Qt Developer Days 2010 and more

Next week I’m going to Qt Developer Days in Munich where I will be attending Qt training and technical talks. And almost just as importantly, meet and talk to people who do related things to what we do at Openismus.  I suspect the overall style and feel of this conference will be quite different from past free and open source software events I’ve been to (like GUADEC and Libre Graphics Meeting). More business-y, perhaps even enterprise-y? None the less,  looking forward to it.

In related news, I’m also involved as part of the local team for Desktop Summit 2011, along with several of my co-workers. The initial announcements have just been made public; the conference will be held in Berlin August 6th-12th, at Humboldt University. Mark your calendars 😉 See for instance the story by the GNOME Foundation, the official website or the original announcement for more information.

Hopefully I will also be going to the Meego conference in Dublin in November. Fingers crossed!