cairooverlay: Generic Cairo overlay element for GStreamer

Posted on11 Comments

I wrote the initial version of this in late January, and after some interations it was merged yesterday to gst-plugins-good, and will be in gst-plugins-good 0.10.33. This solves the feature request I filed in 2009, one of my oldest bugreports in bugs.gnome.org!

What does it do?

cairooverlay allows you to draw arbitrary things on top of a video stream in GStreamer using Cairo. Previously you had to create a custom GStreamer element for that (in C/Vala), but now you can just hook up to some signals, using any programming language with GStreamer/Cairo bindings.

To draw an overlay using this element, you use the “caps-updated” signal to get information about the video stream (like width and height) and the “draw” signal to do the actual drawing. In addition to the Cairo context, the draw signal passes you the timestamp and duration of the buffer, so you can also do animations.

For more info see the included example application or the documentation (should be updated soon). Here is the obligatory screenshot showing the example application drawing a heart onto a test videostream:

GStreamer + Cairo = <3

The heart is actually animated, so I guess I should have had a video. But you’ll just have to trust me that it is very cute, or grab the code yourself!

FOSDEM 2011

Posted onLeave a comment

Last weekend I was in Brussels for my first FOSDEM.

Friday I attended a planning meeting for this years Desktop Summit. Several things were on the agenda, the most pressing being the website and the call for papers which both should be finished in the coming month. I was tasked with organizing the call for BoF/meetings/devrooms. In a broader scope, I see my role as making sure relevant non-KDE and GNOME projects know they are welcome. People involved in such projects are welcomed to submit talk proposals, or apply for space for a BoF/meeting just like a KDE/GNOME project, but for anything to come out of it we need to communicate this properly.

Didn’t go to a lot of talks, but I had plenty of good discussions in the “hallway track” and in the evening events. Especially good was meeting up with Claudio Saavedra to discuss Meego Input Methods and the Gtk+ integration he is working on. I hope I was able to help him a bit in getting started.

Attended the Libre Graphics Meeting planning dinner sunday evening. I don’t know if I’m able to make it to the conference yet, so I did not have that much to contribute, but I let them that Libre Graphics projects are welcome to the Desktop Summit. And that I might try to organize a MyPaint workshop at LGM.

Want to integrate with the Meego Netbook UX panel?

Posted onLeave a comment

It is not well communicated, but you can apparently write your own “tabs”/”panes” for the panel/toolbar found in the Meego Netbook UX. Hopefully this blogpost helps a tiny bit*.

As stated by the libmeego-panel/docs/README in the source tree of mutter-meego there are convenience APIs for GTK+ and Clutter based implementations. But it seems you can also just use the DBUS API, in case you prefer Qt or something else. I found this out by searching though meego.gitorious.org after someone asked on #meego

*Since this should be documented in the platform API, I’ve of course filed a bugreport.

MyPaint on Meego?

Posted onLeave a comment

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

Posted onLeave a comment

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

Posted on2 Comments

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

Posted on1 Comment

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

Posted on2 Comments

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

Posted onLeave a comment

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.