Postings tagged with GNOME

The Movie Database, Grilo and mock testing

This year at Openismus had a strong focus on media files and related metadata. So it isn't surprising that we also got in touch with Grilo. Grilo is a framework for discovering media files and decorating it with relevant metadata. One missing piece was background information about movies, like story summaries, artwork, information about artists. With the support of our customers we decided to change that.

Now an obvious choice for getting information on movies is Amazon's incredibly comprehensive Internet Movie Database. Sadly there doesn't seem to be any official web API that could be used by open source software. If I missed something, please tell me in the comments.

The Movie Database plugin for Grilo

Anyway, with IMDb out of reach we had to look for an alternative - and we've found a great one: The Movie Database. This database is a community driven project, built with the needs of media players in mind. It comes with a great and easy to use API. Like IMDb it seems to know just each and every relevant and irrelevant movie ever made. Some entertaining stuff like movie trivia, goofs and quotes are missing, but for most movies the database knows the IMDb id - so all the entertainment is just one click away.

Now that we've found a good movie database Jens started implementing a TMDb plugin for Grilo, and a first version of the plugin was released with grilo-plugins 0.2.2. I've later finished it while integrating it with our customer's project. Murray took care of examples and documentation.

The plugin implements a metadata resolver: It takes a media object, checks for a title or the unique movie id and then fills the media object with information it found on TMDb. Biggest obstacle when using the plugin is the need for an API key. It should be easy to get. The database operator hope these keys will help them to deal with misbehaving clients.

Another issue is related to Grilo's architecture. Grilo doesn't permit its sources to improve any metadata. So if you interpolated a movie title from the filename and pass a media object with that title to the TMDb plugin, the plugin is not permitted to replace your usually ugly title with the pretty and official title it found in the database. To work around that issue you would not resolve the TMDb data in a single step. Instead you'd do a first resolve operation to just retrieve the TMDb's movie id. In a second step you'd delete your own title, but keep the resolved movie id and let the plugin work with that data:

/* Create dummy media from filename */
media = grl_media_new ();
grl_media_set_title (media, "the_last_unicorn_720p");

/* Ask grilo to resolve the TMDb id */
metadata_key_tmdb_id = grl_registry_lookup_metadata_key (registry, "tmdb-id");
keys = grl_metadata_key_list_new (metadata_key_tmdb_id, GRL_METADATA_KEY_INVALID);
grl_source_resolve_sync (source, media, keys, options, &error);
/* Exercise: Release memory and handle possible errors */

/* Use the resolved id to get full metadata */
movie_id = grl_data_get_string (GRL_DATA (media), metadata_key_tmdb_id);

if (movie_id) {
    grl_data_remove (GRL_DATA (media), GRL_METADATA_KEY_TITLE);
    grl_source_resolve_sync (source, media, keys, options, &error);
    /* ... */

Behind your back the same number of network requests is needed for both approaches.

Testing the Plugin

At Openismus we have a mantra we strongly believe in:

No code is done before it has proper tests.

Or more radically:

It doesn't work if it isn't tested.

In the case of the TMDb plugin this commitment caused us a bit of work. Grilo didn't have any infrastructure for testing network based plugins yet. Also if we'd do those tests we'd like to run them offline:

So we took the challenge and also implemented a mock testing framework for Grilo. It became handy that Grilo already routes all its network access through a dedicated abstraction, so that it can implement request throttling. So we just hooked into that layer and introduced a few environment variables that influence behavior of that layer: First you'd set GRL_NET_CAPTURE_DIR to some folder name and then let your plugin perform a few interesting operations. In a next step you'd edit the recorded files and rename them nicely to suite your needs. Essential in that work is a generated key-value file of the name grl-net-mock-data-$PID.ini which maps URLs to captured responses. Once done you can set GRL_NET_MOCKED to point to that file. Grilo will then stop doing real network requests and answer all requests with the information this file provides.

Details about testing with the Grilo mock framework are in the reference manual. A few examples for using the framework can be found in Grilo's test folder.

Performance and Memory Usage of Evolution Data Server

Openismus asked me to perform some benchmarks on Evolution Data Server. We wanted to track the progress of recent performance improvements and identify possible improvements. Therefore, I tested these versions of EDS:

The code is in a phonebooks-benchmarks repository on Gitorious with a full auotools build, and with a script to build and test all these versions of EDS. So you can try this too, and you can help to correct or improve the benchmarks. See below for details.

EDS offers various APIs to access the address book. The traditional interface was EBook, which has served us well in GNOME 2 and Maemo 5. However, some APIs such as batch saving are missing in the upstream version. Also its asynchronous API doesn't follow the conventions established later by GIO. To overcome these EBook shortcomings, and to make efficient use of GDBus, the EBookClient API was added in EDS 3.2. We can even use the backend EDataBook API, and that lets us measure the overhead imposed by using D-Bus.

I tested the back-ends with different numbers of contacts. For each benchmark, and for each contact count, we create an entirely new private database. D-Bus communication was moved to a private D-Bus session. To avoid swapping, the maximum virtual memory size was limited to 2 GiB per ulimit command. This limit probably caused the crash of Maemo 5's EDS in the test with 12,800 contacts, but I have not checked that yet.

Contact Saving

These benchmarks simply store a list of parsed contacts in the address book. This simulates use cases such as the initial import of contacts upon migration or synchronization.

To avoid possible side effects from lazy parsing, we retrieve the attribute list for each contact before starting the benchmark. With EBook from Maemo 5 and EBookClient since EDS 3.4, contacts are saved in batches of 3,200 contacts. This partitioning was needed to deal with resource limitations in the file backend. All other EDS variants must save their contacts one by one.

Contact saving, without batching

EBook, EBookClient, EDataBook implementation

As expected, the effort for contact saving grows quickly when not using a batch API. This is because a new database transaction must be created and committed for each contact. Things look much better when using the batch saving API which was available in Maemo 5 already, and was recently added to EBookClient:

Contact saving in batches

Batch saving performance of EDS 3.4+ is just excellent: Although slowly growing with the number of contacts, it remains below a threshold of 3 ms per contact even for 12,800 contacts. That growing effort can be accounted to growing attribute indices. The initial peak (until 50 contacts for Maemo 5, and until 400 contacts for EDS 3.4+) can be accounted to database setup cost.

In terms of performance there is no difference between using EBookClient or EDataBook (which avoids D-Bus).

Contact Fetching

A very basic, but essential, benchmark is fetching all contacts. To get a first impression I just fetched all contacts without any constraints.

Fetch all contacts

EBook, EBookClient, EDataBook implementation

Contact fetching performance decreased significantly during the EDS 3 series and then got better again: Fetching all contacts with 3.4 takes about 133% of the time that EDS 2.32 needs and even 225% of Maemo 5's time. With EDS 3.5 contact loading time is improving again, making the EBook version of EDS 3.5 comparable in performance to EDS 2.32. Git archeology and quick testing identifies Christophe Dumez's bugfix as the relevant change. Apparently the file backend didn't make optimal use of Berkeley DB transactions.

Still there is significant room for improvement, because:

  1. simple contact fetching with EBook 3.5 still takes 175% of the time Maemo 5 needs.
  2. EBookClient 3.5 is still 20% slower than EBook 3.5, and 64% slower than EDataBook.

This basic test shows already that the chosen client-server architecture of EDS causes a non-ignorable overhead.

It would be absolutely worth investigating how Maemo 5 reaches its far superior performance: After all it even beats EDataBook. I remember having spent significant time on avoiding vCard parsing and string copying. I also remember having replaced the rather inefficient GList with GPtrArray at several places. Some of the ideas have been ported upstream during Openismus' work for Intel. Apparently there are more gems to recover.

Fetching by UID

Fetching contacts by UID simulates lazy loading of contact lists: Initially, we only fetch contact IDs. We only fetch the full contacts when the device becomes idle, or when contacts become visible on screen. This approach is needed because even the fastest implementation (Maemo 5) needs several seconds to fetch any contact list of realistical size on mobile hardware. Another useful optimization we implemented on the Nokia N9 is fetching of partial contacts, that only contain relevant information, like for instance the person's name. EDS doesn't support this optimization.

As a first test we fetch contacts one-by-one, without using any kind of batch API:

Fetch by UID without batches

EBook, EBookClient, EDataBook implementation

The good news is that this chart shows quite constant performance for each client.

The bad news is that contact fetching is pretty slow: 3.9 ms per contact, as seen with EDS 3.5, translates roughly to 390 ms to fetch only 100 contacts on this hardware. Considering that typical mobile devices are roughly 10 times slower than my notebook, these numbers are disappointing. Especially if you consider that EDS 2.32 was about 4 times, and Maemo 5 even about 13 times faster. This are entirely different worlds. It should be investigated what causes this significant performance regression from EDS 2.32 to EDS 3.2+. One also should try to port the performance fixes of Maemo 5.

The performance reachable under ideal circumstances is shown by the EDataBook client. This only needs about 50 µs (0.05 ms) to fetch one contact by its id. Directly accessing the address book via EDataBook is about two orders of magnitude faster than the current EBookClient. That's the goal that EDS can, and should, aim for. Apparently a significant amount of time is spent on performing D-Bus communication, whereas the requested task can be performed by the backend within almost no time.

However, this data was acquired by fetching the contacts one by one. We can surely do better by using a batch API. That should drastically reduce the overhead caused, for instance, by D-Bus. But neither EBook or EBookClient provide an API to fetch contacts by lists of contact IDs. The thing that comes closest is filtering the contacts by a disjunction of UID field tests:

(or (is "id" "uid1") (is "id" "id2") ...)

So I tried that. The results for such queries, using batches of UIDs, look like this:

Fetch by UID in huge batches

EBook, EBookClient, EDataBook implementation

This chart speaks for itself. To remain responsive and appear fluid while scrolling, applications should render at 60 frames per second. To reach that framerate newly visible contacts must be fetched and rendered within less than 16 ms. EDS apparently cannot meet that performance goal even on desktop computers. Considering the huge performance differences between client-server access and direct access, as seen when fetching contacts one by one, it seems very worthwhile to add dedicated support for fetching multiple contacts by UID. The most obvious approach would be adding a batch API in the spirit of e_book_client_add_contacts(). Another solution would be adding more fast paths to the query processing code.


EBook, EBookClient, EDataBook implementation, the queries used

Contact filtering is relatively efficient when using fields such as last-name, for which indices are hit. Still, the D-Bus overhead is noticeable: EDataBook needs less than 60% of EBook's or EBookClient's time.

The times to match long prefixes and suffixes look quite similar when hitting indices.

The behavior of EBook for short name prefixes is a bit strange. The EBook API is now deprecated, but it could still be worthwhile to identify the issue causing this strange behavior, so that it can be avoided in the future:

Interestingly, there seem to be no functional database indices for email addresses or phone numbers in more recent versions of EDS:

The behavior of Maemo 5's EDS is a bit surprising, as I know that Rob spent significant amounts of time on adding Berkeley DB based indices to that EDS version.

It might be worth optimizing index usage in EDS, because prefix and suffix searches are commonly used in mobile applications. Prefix searches need to be fast, for quick feedback during auto completion. Suffix searches need to be fast, for instance to provide instant caller identification.

Memory Usage

Memory is cheap those days. Still, especially on embedded devices, you should keep a close eye on the memory consumption of your software. Obviously, memory consumption grows with the number of contacts used:

Resident Set Size (RSS)

It's nice to see how memory consumption has reduced from release to release. It's also good to see that EBookClient seems to use slightly less memory than EBook.

You might miss the graphs for Maemo 5 and EDS 2.32. I had to drop them for this chart as they show serious memory leaks, preventing any useful examination. Apparently the leak really is in those versions of EDS: The EBook benchmarks for EDS 3.2+ are using exactly the same code but don't show this bad behavior.

Notice that I've accumulated the client's and the backend's memory consumption. This allows us to estimate the cost of EDS's client-server architecture. Apparently this architecture increases memory consumption by about 40% in these benchmarks.

While the RSS usage gives us information about the efficiency and correctness of the code, it's also interesting to check the virtual memory size needed by the benchmarks. Please take the following numbers with a reasonable grain of salt: I got these numbers by simply adding together the virtual memory size of the client and of the backend process, as reported by the processes' status file. A proper measurement would process the maps file to properly account for shared memory regions.

Virtual Memory Size (VMS)

The first issue we notice is the massively increased memory usage of EBookClient 3.2. It's almost 40% more than the others. Fortunately, the issue seems to have been fixed already in EDS 3.4.

At first glance, the very low virtual memory usage of the EDataBook benchmark is impressive. It seems to consume only 40% of the client-server based benchmarks. Still, there is a fairly high chance that this huge delta must be attributed to my poor measurement here: Assuming perfect code segment sharing there only remains a delta of about 20 MiB, which would be nothing but the RSS delta of EDataBook and EBookClient. It would be nice to investigate this in more detail.

RSS usage per contact

This chart shows the memory per contact after the contact saving benchmark. The overall memory usage per contact has grown dramatically by almost 40% in EDS 3+. The most efficient approach is apparently to directly access EDataBook, which consumes only 55% of the RSS per contact, compared to the client-server approaches.

RSS usage per contact, model only

This high memory usage per contact is a bit surprising since, after subtracting effects from library and database initialization, the memory usage per contact remained constant between EDS 2.32 and EDS 3.5. The parallel usage of both Berkeley DB and SQLite in the file backend might be to blame, but this is currently pure speculation from me.

The temporary regression in EDS 3.2 was apparently fixed. The increased memory usage of EBookClient and EDataBook over EBook is because the EBookClient and EDataBook benchmarks, in a slightly unrealistic bias for performance, store both the EContact and the VCard string for each contact.


The developers of Evolution Data Server have paid good attention to performance and have successfully implemented significant improvements. However, EDS releases regularly suffer performance regressions, and the performance of EDS still isn't good enough for usage in mobile devices. Fortunately the performance problems are solvable. Some fixes will be straightforward, such as adding more batch API (or fast paths) for query processing. Others will need careful performance monitoring: For instance when activating more database indices, to speed up queries, we must be careful not to slow down contact saving.

A not so trivial improvement would be adding a direct access API for reading the local database. The speed and memory usage measurements show the value of such API: Direct access is significantly faster than via D-Bus in most usage cases, and it seems to significantly reduce memory usage.

Another significant improvement should be finishing the file backend's transition to SQLite: Using two database backends in parallel significantly increases code complexity and has measurably bad impact on memory consumption.

Usage Instructions

The full source code of this project is in our phonebooks-benchmarks repository on Gitorious. You'll need a fairly recent C++ compiler because I also used this project to get more familiar with the new features of C++11. I've successfully tested g++ 4.6.3 and g++ 4.7.0. Clang 3.0 definitely won't work because of incomplete lambda support.

Other than that, you'll need Boost 1.48 to compile the benchmarks. The optional chart-drawing module uses ImageMagick++ and MathGL 2.0.2.

There is a simple script for building and installing the tested EDS versions. The configure script will give instructions.

To finally run the benchmarks just call src/phonebook-benchmarks, and to draw the charts run src/phonebook-benchmarks-mkcharts.

When doing your own tests that needs a non-trivial vCard generator take look at src/phonebook-benchmarks-mkvcards.


It would be interesting to take a more detailed look at the virtual memory usage.

Also it would be educational to compare these results with other address book implementations. The first candidates I have in mind are QtContacts on Tracker and Tizen's native contacts API.

We didn't cover EBookView and EBookClientView yet. These views take a query and notify the application when the contact set matching the query has changed. Typically, every user interface needs to use them.

We also didn't talk about the calendar API yet.

Well, and most importantly we at Openismus would enjoy fixing the identified performance problems.


FOSDEM is only real with Belgian Waffles FOSDEM in 2012 was an exciting (and naturally, exhaustive) conference again. It's great to have so many relevant people who are all active in the free software world together in one place. It's also a great opportunity to discuss radical new ideas, ideally while experimenting with Belgium beer. Which is what we usually did when we weren't at the conference site.

It was nice to see Jarno and Esko at the conference, too. We even stayed in the same hotel. I hope they enjoyed the Ethiopian lunch as much as I did. And perhaps they're not too angry any more that we lead them to drink Absinthe ;-)

Jon and I gave two talks. Jon's talk (slides) was about Maliit as a project, explaining what Maliit is (and what it is not), combined with a short history lesson about the project. I tried to outline the difficulties of mobile text input in general (slides), picking some use-cases that are known from the desktop world and showing why simply copying the use-cases and their known interaction models does not work very well. I honestly liked Jon's talk more though.

Neither of us two actually managed to visit other talks, even though we wanted to. We had to ask Jarno, Esko and others about what great talks we missed. Apparently there were quite a few :-(

Our Maliit T-Shirts were well received, though we usually only handed them out when someone listened to our Maliit ramblings long enough.

We were asked about accessibility several times, which is currently not within the scope of Maliit but perhaps something to think about in the future.

We also got to talk with the people working on (text) input in Redhat and Intel, mostly in the context of Wayland. There are some interesting opportunities to get things (more) right this time around.

Thanks to our employer, Openismus, for sending us there!

The infrastructure of the Maliit project

Maliit T-Shirts! It took us a while to transform the Maliit project into a real opensource project. At first there was only public code, later some wiki pages @ meego.com together with constantly changing components in the official MeeGo bugtracker, then a public mailing list.

After that we tried to become independent of MeeGo, but neither freedesktop.org nor the GNOME project could give us a suitable home. So we had to go with our own infrastructure in the end, which probably was the best we could do, in any case. We now enjoy our own website (mostly a wiki, for which we can also analyze the traffic), our own IRC channel, our own public bugtracker, our own mailing lists and a build bot. We also make use of other services such as launchpad.org and the openSUSE Build Service, both for packaging but also as part of our continouous integration setup. Both services provide nightly builds for Maliit, for example (though we still lack packages for ARM).

But there was always one thing missing: T-Shirts. Now that this is solved, too, we can finally call Maliit a real opensource project ;-) Hopefully we'll soon have another group photo of the people who've been involved in the project over the years. I'll make sure to bring a couple of T-Shirts to FOSDEM, so make sure grab Jon or me if you want one.

How we enable others to write 3rd party plugins with Maliit

We finally published a video about Maliit - an input method framework including a virtual keyboard - and 3rd party plugins. Kudos goes to Jon for making time for that.

This video highlights one of Maliit's key features: pluggable input methods which come with their very own user interfaces. The Chinese input methods show how Maliit offers support for composed characters. The video is proof that 3rd party development for Maliit (open-source and proprietary) is not only possible but also happening.

maliit.org states that "it should be easy to customize existing input methods or develop powerful new input methods, whether for profit, research or fun", we actually mean it.

The harder question is of course how to motivate others to actually get started on input method development with Maliit. For that, we have a multipronged strategy:

  1. Provide sufficiently polished reference plugins that can show off Maliit capabilities but also serve as inspiration for new plugins (hence the BSD license for reference plugins). Our reference plugins are currently using Qt/C++ (Maliit Keyboard) and QML (Nemo Keyboard). We also have PySide support, but no one contributed a reference plugin yet. This gives choice to interested input method developers, and we think that's important. The reference plugins serve another role when it comes to designing new API: They become our testbed, allowing us to verify our API proposals.

  2. Ship Maliit with a bunch of example plugins and example applications. None of them try to be complete. They are all self-contained though and usually show one feature at a time. This can be tedious to maintain, but we believe that examples need to stay small and focused, otherwise developers won't look at them.

  3. Documentation that is easy to consume. Our documentation is not as concise and clear as we'd like it to be, but it's slowly improving. We also experiment with videos that can serve as an introduction to more in-depth (text) documentation.

  4. Packages for most common Linux distributions. This one seems obvious, but sadly, it's quite a lot of work for us to keep up with it (and we already use automated services such as Launchpad and OpenSuse Build Service). In the hope to attract dedicated packagers we wrote down some packaging guidelines

  5. An architecture that had 3rd party plugins and multiple toolkit support in mind from the start. The plugin developer facing API needs to be easy to use and clearly documented. This will be the focus of the upcoming 0.9x series.

We will demo Maliit @ FOSDEM 2012, hope to see you there!

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.

Better GTK+ support in Maliit

So far, using Maliit's virtual keyboard in GTK+ applications required fetching and compiling a GTK+ input method brigde yourself. Not any more. With the latest release, GTK+ applications should just work out of the box, thanks to Jon's integration efforts. Right at the same time, Łukasz was looking into using Maliit together with GTK+ applications on his Ubuntu desktop. He did a great job testing Jon's improvement and also contributed patches to properly update GTK+'s input method module cache. When compared to the Qt support, the gap in terms of supported features is quite large. We would like to further improve the GTK+ support and contributions are certainly welcome.

Better key override support for Maliit

Dynamic key overrides in Maliit's Quick plugin

Krzesimir Nowak joined Openismus in the beginning of August this year. Not only is he a very talented developer (or, as I once said, the first one to actually fill the gap Daniel left), but he's also fun to work with.

Just before I went on my vacations in September, I left him with some nice tasks to improve one of the cool features in Maliit: Dynamic key overrides. The way I had set up the tasks I knew he would trip over bits of hideous code and seeing how he could deal with it was part of the exercise.

For now, Krzesimir's work on Maliit is finished. With 25 commits, two of them being bug fixes in said ugly code, Krzesimir did an outstanding job while thoroughly understanding and fixing one of Maliit's core features in a rather short time span. Of course he will tell you that it took him way too long ;-)

Thanks for your contribution, Krzesimir, and well done!

Real users, real feedback

Maliit on the N9

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!

They call us crazy, but we store Contacts in Tracker

Visa authorities playing bad games with Chandni gave me the chance to talk about the QtContacts tracker plugin, which I and others where working on for that past few months. In case you've missed that early talk, here are the slides.

Interesting to just watch George from KDE to talk about similar things.

Desktop Summit 2011

Premature bad taste becomes the norm

Seems premature bad taste becomes the norm in GNOME land.

Seems that video was shown at the desktop summit's GNOME: state of the union talk. Despite that the subtitles are entirely off, the German dialog behind is about the final days of WWII involving street fights and total destruction of Berlin.

That's nothing to make fun of. Is that really how GNOME wants to present itself?

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.

Nokia's N9

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.

Is MeeGo Keyboard conquering GNOME3?

Maliit in GNOME3

You'd probably like me more if I had spend my time testing the upcoming release of MeeGo Tablet UX on this shiny new WeTab (I ♥ Openismus), but Jon couldn't resist to test-drive GNOME3 first. Well, and since we like our virtual keyboard so much, we just had to make it work of course.

Jon also wrote about the features shown in the video.

Time for patches

Not happy with GNOME Shell, not happy with Unity, not happy with alternatives. Seems it is time for starting the editor again and cooking patches. Merging the good ideas from GNOME Shell and Unity. Ripping out the crap. Well, making it possible to hide: Some people believe in it - fine.

Still wondering which of the two I'll work with.

Really sucks that people allowed this split to happen. Both teams have good ideas. Both teams have bad ideas. Both teams are motivated. Good leaders would not have permitted this split to happen.

Well, back to fetching source code, reading documentation, understanding what's going on.

Big fears wether I am able to get my code upstream. Both teams appear narrow-minded from outside. Guess I'll need a (good) plan.

Not ready to give up yet. Want a modern free desktop, which suites my needs. Not a corset.

Wondering where to steal the massive amount of time needed.

Automatic suspend when closing the lid

There is this big discussion about automatic suspend when closing lid as only user visible option going on. Let me share a little tale about the implications of that feature:

A long, long time ago... A young student just bought his first notebook few weeks ago and this was a big thing as even such entry class notebooks were really expensive those days. After long studying and working on assignments this student decided it's about time to get home, closed the lid of his brandnew notebook to let it suspend, put it into his bag and walked out of the building. He had to take the train to get home. As always at this time the train was crowded. No chance to take the notebook out. Two hours later or something that guy was home, had eaten something and took the notebook out of his bag to face shocking news: Automatic suspend didn't work, the notebook was running all the time in the bag. Bad air circulation had killed the notebook.

Without giving the user a visibile option to disable automatic suspend, with teaching users to really on this inherent unreliable feature (applications shall be permitted to inhibit suspend!), I really wonder if GNOME has put money aside to compensate users killing their notebooks with broken automatic suspend.

PS: It was my notebook dying, and I spent something like EUR 1.800 back those days.

PPS: I know the (L)GPL's no-warrenty clause, but I am not convinced it holds in court for such obvious misbehavior (INAL).

Application Theming Tricks

From time to time applications need custom theming rules. Especially when the project has professional UI designers involved. So how to achieve this with GTK+?

Trivial Theming

Most easy and very wrong:

if (gdk_color_parse ("pink", &color))
    gtk_widget_modify_bg (widget, GTK_STATE_NORMAL, &color);

This will break and look childish as soon as your users use a custom color scheme.


static void
style_set_cb (GtkWidget *widget,
              GtkStyle *old_style)
    GtkStyle *style = gtk_widget_get_style (widget);

    if (gtk_style_lookup_color (style, "SecondaryTextColor", &color))
        gtk_widget_modify_bg (widget, GTK_STATE_NORMAL, &color);

static void
my_widget_init (MyWidget *widget)
    g_signal_connect (widget, "style-set", G_CALLBACK (style_set_cb), NULL);

This will allow theme designers to override your color choice. Notice that you'll have to update those color overrides when the theme changes. Btw, the "style-set" signal is emitted when the widget is realized, therefore you don't have to manually invoke the callback during widget construction.

Guess it's also worth to mention that Hildon provides convenience API for simple theming requirements.

Complex Problems

So for simple requirements GTK+ (and Hildon) have reasonable API support. Things become troublesome when your designers invent rules like "this widget has a rounded border and drop shadow, but only within buttons". Obviously border and drop shadow radius should be themeable and therefore are implemented as style properties, but how to impose this rule?

You could scan the widget hierarchy when choosing default values for your style properties:

button = gtk_widget_get_ancestor (widget, GTK_TYPE_BUTTON);
gtk_widget_style_get (widget, "border-radius", &border_radius, NULL);

if (button)
    border_radius = (button ? 12 : 0);

You'll quickly notice the flawed hard coded default value. Also such things are hard to override in theme files. So it's probably better to apply a custom theming rule via gtk_rc_parse_string():

static void
my_widget_class_init (MyWidgetClass *class)
        ("style 'my-widget-style-clickable' {"
         "    MyWidget::border-radius = 2"
         "widget_class '*.<GtkButton>.MyWidget'"
         "style 'my-widget-style-clickable''");

Application Theme Files

Looks like a perfect solution, until you realize that this rule is applied after all rules loaded from gtkrc files!

So how to inject this rule before the user's theming rules? This was a big question to me until I've found gtk_rc_add_default_file(). Well almost: This function only adds files to the end of the search path. Therefore it suffers from the same issues as gtk_rc_parse_string(). Fortunately the API author was smart enough to also provide gtk_rc_get_default_files() and gtk_rc_set_default_files(). Those functions can be used to apply application specific theming rules, which can be overwritten by the user - drum roll please:

static void
inject_rc_file (const char *filename)
    char **system_rc_files, **p;
    GPtrArray *custom_rc_files;

    system_rc_files = gtk_rc_get_default_files ();
    custom_rc_files = g_ptr_array_new ();

    g_ptr_array_add (custom_rc_files, g_strdup (filename));

    for (p = system_rc_files; *p; ++p)
            g_ptr_array_add (custom_rc_files, g_strdup (*p));

    g_ptr_array_add (custom_rc_files, NULL);

    gtk_rc_set_default_files ((gpointer) custom_rc_files->pdata);
    g_strfreev ((gpointer) g_ptr_array_free (custom_rc_files, FALSE));

main (int argc,
      char **argv)
    inject_rc_file (PKGDATADIR "/gtkrc." PACKAGE);
    gtk_init (&argc, &argv);

Update: Benjamin Berg just pointed out that priorities can be assigned to styles. So the following should work fine:

    ("style 'my-widget-style-clickable' {"
     " MyWidget::border-radius = 2"
     "widget_class '*.<GtkButton>.MyWidget'"
     "style : lowest 'my-widget-style-clickable''");

Awesome, little know feature.

See you at the Prater Biergarten

Let's have a small GNOMEr's come-together in Berlin's Prater Biergarten this Friday at 16:00.

Audio File Preview

I am probably the last guy who discovered the preview feature for audio files in GNOME. Nevertheless I have a strong opinion about it, perhaps because of the way I made my first contact with it.

I have auto-login enabled for my GNOME session, which means the mouse pointer starts in the center of the screen. Now I also have a cluttered desktop and some of the files were actually audio files. Totally by random, one of them made to the center of the desktop. Wow - what a nasty surprise next time I started up the machine: My box autoplays music!?

Of course it doesn't, I only triggered the audio file preview by hovering the mouse pointer over the file's icon for a few seconds. There are several things I dislike about that:

As it is, this feature isn't easily discovered. If you discover it, chances are good it will confuse you. Solutions? Or is it only annoying to me?

Reviewing Patches

One of the new Giggle features I am most proud of is the new patch view, which only shows one chunk at a time and let's you navigate between chunks using the file list, toolbar buttons or hotkeys (Alt+Up, Alt+Down). At the same time it also is the most criticised feature of the new Giggle. So I wonder how to improve that view.

Giggle Diff View

I've introduced that feature because seeing the entire patch at a time distracts me easily. When reviewing patches I want to focus on one change at a time. Clearly not an option (in my opinion) is to introduce a switch to just show the full patch. I'd break that mode far too often cause I'd never use it. That opinion is based on Havoc Pennington's excellent article about "Free software UI". Don't miss the chapter "The Question of Preferences".

So I want to know:

  1. Why is seeing the entire patch important for you?
  2. How much information do you need from a patch at a time?
  3. Which ideas do you have for improving the patch view?

Keeping my own ideas for myself right now, as I am playing the "Ask the Audience" lifeline.

Giggle 0.4.90

Lennart just poked me if it isn't about time to make a Giggle release. There are more than 248 commits since the last release, seems he is right.

Code, wiki and bug tracker have been moved from Immendio to github, live.gnome.org and bugzilla.gnome.org.

What has changed since 0.4? Quite alot. Most important changes are those:

Note that this is an unstable development release. It still contains quite some bugs and reggressions.

Tarballs are are ftp.gnome.org:

Learning GTK+

During the last weeks I started to learn about the GTK+. I mostly followed the official tutorial but soon tried to walk on my own legs. Perhaps that was not always the best choice, as I ran into dead ends later (I skipped some chapters which probably were important, but their title did not give it away). Requiring sequential reading is so 1999 ...

Now why is the GTK+ awesome? Simple, when using the GTK+ you almost forget you write in portable macro assembler. Pointers are annotated with a nice semantic (reference to an object, comparable to what languages with OO support see in variables), and memory management is usually none of your concern.

The next feature I was impressed with is type-checking since it gives you valuable hints whether you got the semantics of your pointers right. Granted, most of it happens at runtime, and it does not come without costs. But how else would you do it in C?

Also, I do like the approach of the GTK+ to not enforce a pixel-based layout. The GTK+ will negotiate the appropiate window size for your widgets, and it will re-negotiate it once you remove/hide widgets from your layout. This all comes for free together with the object hierarchy you create when you define the ownership relation of your widgets.

However, as soon as you start writing custom widgets it all gets a bit hairy. The good news are that for one, this part is well-documented on the web, and also that once you created a custom widget it can be used just as easily as the built-in widget types. Should that not be enough to encourage you to go the extra steps necessary then simply take it as a valuable lesson about "Implementing Object Orientation from Scratch".

And then I came across GObject properties. It all looked cumbersome, for little gain. At first I feared I would even have to pack everything into GValues before I can access properties, but luckily there is g_object_set() (and not g_object_set_property(), as you might have guessed). Now if properties could be made to react to signals directly ...

Overall, I like the GTK+ so far. Some things could be more obvious, some other things you just have to accept as god-given, and the rest seems dead-simple. If you are undecided which GUI toolkit to learn then perhaps the long list of available language bindings (quality may vary) is convincing to you. Learn once, use everywhere :-)

GtkBuilder based Plugin System

Seems like GtkBuilder is extremly useful to build efficient plugin systems:

The prettyness of this system is, that it only loads the plugin when some related action is activated:

Implementing this was straightforward. I am pretty sure that I've reinvented some wheel.

Blur Effect with cairo

Wondered how to apply convolution filters, like for instance gaussian blur in cairo. Doesn't seem to be possible yet. Well, unless you remember that cairo uses pixman as backend for its image surface. Result of my hacks below:

Blur Effect with cairo

The code is in the blur_image_surface() function of blur-effect.c. Now the question is how to make a nice cairo API for this code, and how to hardware accelerate this. At least XRender seems to define API for convolution filters.

Update: Get full code via git clone http://taschenorakel.de/git/playground

Static Panel Nonsense

Vuntz, you ask for angry reactions, here is your first one: This static panel stuff is the biggest nonsense I've seen in years! You've presented us an early April's fool joke, didn't you?

Please visit some real people and look at their Windows or OSX desktop, look how they customized the Quick-Launch area respectively their dock and then come again, please.

Important hint: Whenever you try to improve something, you should be as good as the old solution at least. Otherwise you just wasted time.

Come on: You don't really expect users to do several clicks for launching their prefered application, if the current, customizable panel supports this with one single click? Sorry, but the ability to add application launchers to one promiment one-click-location is an essential feature of each desktop shell. And no! I also don't want this list to be generated automatically: I'd feel ashamed if my desktop would tell everyone at a short glimpse, that Solitare is my favorite application.

Well, or if you guys really are convinced of this crap, do it in a side project please, but don't destroy GNOME's desktop shell.

PS: That's how my desktop looks like right now, and I am extremly happy with it.

My GNOME Desktop

Notice how I've disabled desktop icons, since they cause just clutter. Notice how I've filled the bottom panel with information more useful than the task list applet. The very first icon of that panel opens a popup with all current windows. This works much better for finding lost windows than this obscure task.

Update: Btw, you might think that my panels contain information you consider not important. Well, good catch, you've found one of my points: Judgement what's essential information largely differs among individuals.

libtool aware gdb wrapper and mergetool

Just want to mention some small and rough tools I've written recently to easy my daily hacker's life:

Both tools are quite rough, but maybe some of you find them useful.

Update: Seems that "libtool --mode=execute cmdline..." works similar to my wrapper script. Thanks for pointing me on this.

Changelogs and Fortune Cookies

Nasrudin walked into a teahouse and declaimed, "The moon is more useful than the sun."
"Why?", he was asked.
"Because at night we need the light more."

Regularly applaud myself for changing my prepare-changelog script to yield a random fortune cookie with each changelog entry:

`/usr/games/fortune -s wisdom`

Quite entertaining.

Just take care to remove those cookies before commiting: Some people might get offended by this unexpected and often unrelated wisdoms.

GNOME makes happy people

GNOME is fun. Proof below:

Happy Marc-André stands in the GNOME swag bag

Extensive Gimp tutorial on spiegel.de

http://www.spiegel.de/netzwelt/tech/0,1518,565794,00.html (german only?) - already on the first page the article shows that this time, somebody did his homework, explaining the difference between stable and dev versions.

It then goes further into detail, in a way you would normally expect from your common computer mag.

I wish there were more articles like that in regular newspaper, if only to raise awareness of how good OSS has become over the years. So, what's next? A tutorial on how to use GNOME on your Office PC?

Back from Istanbul

Back from Istanbul. Wow, what an experience. What a vibrant city, thirsty for life! I still have short flashbacks blending memories from Istanbul into my consciousness. Strange experience. Obviously a sign for how much I enjoyed my time there. Quite a mistake to not convince Ulrike to join me for that trip. Awesome how happy Marc-André was when having me back. For the next three days it seemed like he didn't know if I was real or just some dream. Poor little guy: I could just watch photos on my camera or my mobile when I missed him, he couldn't.

Well, but thank you guys for bringing GUADEC to Istanbul. Seems I did a full 180° turn when it comes to this city. I wonder why X-Berg or Wedding aren't half as cool as this place. Well, maybe I just don't know the right places in those areas.

Leaving Gentoo behind - UPDATE

Today I freed myself from that incredible mess Gentoo had become on my box. Having shiny new software again should let me forget the pain quickly. Also, reconfiguring my GNOME desktop was a mere by-product of copying my home folder back onto the box (yay!).

UPDATE: Wow, it makes a huge difference whether you evaluate a distro thouroughly or just give it a quick glance. Lesson learned: Never enter a distro war without having used the other's distro on your desktop for a week. Of course I knew Ubuntu before, and I already installed it on several boxes, too. But only now, as my desktop distro, I realize how much they already got right. For example, my main argument to keep Gentoo was "But - I have a working compiler environment from the start, with all the header files and libraries!" Had I only known before that it takes 2 packages on Ubuntu to get nearly the same functionality .... Funnily enough, Ubuntu isn't any slower, so there's goes the second argument. Leaves USE flags. Though honestly, I rather prefer working dependencies resolvers than having to test for circular ones.

And finally, sound works. It even remembers my settings!

OK, now on the downside: So I wanted to watch some DVDs: I put the DVD in, totem opens (wow, autoplay on Linux - finally!) and instantly prompts me to download the codecs. If only now the DVD would play, it would have been a convincing demonstration to Windows users. But as some may guess, things go downhill from here (sigh) - you need the medibuntu repo to get the right codecs, add a key manually and even then totem won't play the DVD. I had to fetch mplayer (my most favourite player still after all these years) and then it worked. Sadly, less savy users will consider DVD replay to be broken in Ubuntu and give up. So please, even if the codecs are non-free (as in speech), make a proper wizard at least so everyone who can live with non-free codecs will be able to enjoy DVDs on the Linux Desktop.

Karl, calm down!

Karl, calm down please! Well, and don't spread lies!

As you can check yourself in our SVN repository, Zeeshan never has been removed from Planet GNOME. Recent changes to the configuration file all were additions. There is no single removal in the log for the last few weeks!

I really start to worry about all the hateress recently seen on Planet GNOME. I am guilty by myself. What happend to the fun? When did we loose our positive spirit? Are our GNOME related day jobs eating it?

Update: But it really seems like Zeeshan's Ubuntu post has been removed from the Planet's cache. I didn't thought this would be possible, but quickly reading over the aggregator's source code revealed that the planet-cache script has a --hide switch for censoring single posts.

So maybe censorship took place. Time for the responsible person to stand up and to explain what append.

Update2: Change the wording of the above update, since so far we just have indications, no proofs.

Update3: Jeff said on IRC that Zeeshan might just have triggered the two-posts-per person limit. Sounds reasonable, so this affair is over for me.

Nag Screens have reached GNOME now

Dude, this sucks! Really. Nag screens[1] finally have reached GNOME: When you insert a CD unknown to the MusicBrainz database, Sound Juicer shows a nag screen asking you to upload that information to MusicBrainz.

MusicBrainz Nag Screen in Sound Juicer

I understand that people want to support their favorite service, but in the case of MusicBrainz this is support is really annoying: MusicBrainz - at least as integrated into Sound Juicer - doesn't seem to support anonymous contributions, well and seriously I have absolutely no intend to publish a list of any CDs I've ever put into my computer. So MusicBrainz really belongs to those non-free big-brother services I really do not want to be bothered with.

So can we stop this non-sense of advertising non-free services please, before it gets out of control? Not being bored by nag-screens once was one of the big selling points of free desktop environments, do you remember? We really should not give it up easily.

[1] Annoying advertisement for non-free stuff built into computer programs.

PS: Discussion of this issue should probably should happend in Bug 537441.

Follow up: Ross, in the case of Sound Juicer I am user, and users have every right to be pissed, when developers totally screw it. Nevertheless I want to work on this issue. Closing that problem report as "WONT FIX" with each of your comments neither helps to get the problem solved, nor to calm down the situation.

Follow up 2: Hmm... It's 01:04 CEST now, I am cooled down and wonder why I got that upset. Yes, nag-screens are wrong and Sound Juicer tried a good thing, but didn't get this notification 100% right. Guess I should have handled this more silently, well but guess I won't have written a patch at all in that case - which would have been bad. Frustration: Either I piss many people, but finally write a patch - or I react professionally, but also calm down too much, so that I do not care about patching. Clearly suboptimal.

LIRC Properties hosted on gnome.org now

Murray did the neccessary steps for moving GNOME LIRC Properties to GNOME infrastructure now last week. Bugs are tracked in Bugzilla now, and latest source code can be found here: http://svn.gnome.org/svn/gnome-lirc-properties/.

Thanks infrastructure for doing this job quickly. Thanks Fluendo for allowing to move the code.

Just wondering now, when GNOME's awesome I18N team find the module and submits the first translations.

GNOME LIRC Properties

Some time ago Murray announced this little GUI to configure IR remote controls we Openismus guys did for Fluendo. Last Friday the program finally got uploaded to Ubuntu's package archive, since yesterday its package is in Hardy's Universe repository.

The program can detect your IR receiver and suggest a remote control. Success of that choice can be directly tested in the main dialog. There also is support for customizing remote control configuration files, and for learning key codes.

Unfortunately the D-Bus backend of the program only supports Ubuntu right now, well but as usual in such situations: Patches welcome, I guess.

Also we'd like to have a much cleaner interface for using the features of irrecord. Currently we have to simulate a pseudo-terminal (for stdio buffering reasons) and heuristically guess from irrecord's reactions what happens. A nice library for driving LIRC's hardware detection capabilities would be nice to have. Unfortunately we could no do this due various time constraints (Hardy schedule, project schedule, ...).

I have to thank Stefan, Siggi, Mario and Scott for helping to get that package trough the REVU process despite Hardy being in feature freeze already.

I have to thank Andreas for drawing the application icon.

GTK+ Binding Usage

Misread a statement from Mikael Hallendal on gtk-devel-list today.

He wrote:

For example the C# bindings are not on the GNOME bindings page, even
though it is one of the most used and high quality bindings for GTK+.

I read:

it is the most used and high quality bindings for GTK+

Wanted to counter proof this statement he never did, so I ran this tiny script on apt's package list:

for b in libgtk2.0 python-gtk libgtk2.0-cil libgtk2-perl libgtk2-ruby
  c=$(expr 0 $(grep -c "^Depends:.*\\<$b" \
      /var/lib/apt/lists/*archive.ubuntu.com_ubuntu_dists* |\
      sed 's/.*:/+ /'))
  printf '%-15s %5d\n' $b: $c
Gutsy Hardy
libgtk2.0: 1535 1530
python-gtk: 208 221
libgtkmm-2: 85 89
libgtk2.0-cil: 54 54
libgtk2-perl: 42 45
libgtk-(java|jni|cni): 24 22
libgtk2-ruby: 17 18
liblablgtk2-ocaml: 15 15
libgtkada-2: 7 7
libghc6-gtk-dev: 10 5

Nothing surprising it seems.

Update: Readers pointed out that I missed the widely used gtkmm bindings. Added them and some less frequently used bindings. Added emphasis.

GTK+ Hackfest is over

So the GTK+ Hackfest really ended yesterday. I absolutely enjoyed having all you guys arround me. I am absolutely confident, that all the ideas collected and exchanged here will lead to some great GTK+ 3.0 release. It cannot be said often enough, but even in our highly connected world face-to-face meetings are invaluable for our work. This can be understand as invitation to order your tickets for Istanbul right now, if you are uncertain still.

The big BVG strick was a littlebit unfortunate - so we could not use all the U-Bahn stations arround us, to visit other exciting places. Well, but considering how exhausted many were at the end of the week, this reduced mobility probably was a good thing. We could have risked to party too much.

Guess I've learned alot about event organization during that week. Most importantly and as a hint for any successor: Next time I'll sleep on-site instead of driving 50km per day to sleep at home.

I have to thank Behdad for asking me to organize this event and Murray for allowing me to organize this on Openismus time. Thank you dad for helping with the chairs. Thank you Michael for being there on Wednesday. Thank you Ulrike and Marc-André your patience.

Projector for GNOME Events Box

The GTK+ Hackfest has its first positive result already: The GNOME Events Box got a brand new DLP projector. Decision was made to buy one, since renting a projector for a week costs about 200 EUR, wereas you get entry level projectors for only 600 EUR. The Foundation's brand new projector was about 580,99 EUR - including shipment (projector with bag and cables, back side).

Incredible how much technology advanced since I had a projector into my own hands for the last time: It's "just" a 2400 Lumen projector, still it produces a clear and cripsy picture under day light conditions. Awesome.

I also like the fact, that Acer was that kind, to ship not only a German power cable, but also some british and a third one I cannot identify. It looks like an Euro plug with a third pin:

Some stange cable

Update: Seems the third cable has a Swiss plug.

Stop Energy

Wouter - seems I have to reply, since partly I feel responsible for what you call "stop energy". I feel quite sorry, that you experience this as "stop energy", especially since Olav asked for comments. Don't ask for comments, if you do not want to deal with concerns!

Maybe I really should start rationalizing my guts feeling before posting, but as you know rationalizing guts feelings takes some time, so I decided to throw a stopping brick first - before maintainers are forced to follow some bad procedure for the sake of procedure. Without some deeper knowledge about RDF, the entire proposal simply looked like that.

Fortunatly with your great help many concerns have been addressed. Only concern left from my point of view is ensuring, that the RDF files are updated regularly and that they are in sync with traditional meta-data, like AUTHORS, README, COPYING, ...

So can we calm down again, please?

GtkCalendar Details

Hmm... Too much whining on this blog recently. So let's demonstrate some small, but exiting code I've wrote for Openismus, and which will show up in GTK+ 2.16:

 * gtk_calendar_set_detail_func:
 * @calendar: a #GtkCalendar.
 * @func: a function providing details for each day.
 * @data: data to pass to @func invokations.
 * @destroy: a function for releasing @data.
 * Installs a function which provides Pango markup with detail information
 * for each day. Examples for such details are holidays or appointments.
 * That information is shown below each day when #GtkCalendar:show-details
 * is set. A tooltip containing with full detail information is provided,
 * if the entire text should not fit into the details area, or if
 * #GtkCalendar:show-details is not set.
 * The size of the details area can be restricted by setting the
 * #GtkCalendar:detail-width-chars and #GtkCalendar:detail-height-rows
 * properties. 
 * Since: 2.16

How to participate, when your ISP is blacklisted?

Dear Lazy Web, how can I send messages to gtk-devel-list, when my public IP address (better the public IP address of a NAT router in Vodafone's network) is black listed? Using a smart host doesn't help, as that blocked IP address shows up in the "Received:" mail headers. Using web mail also doesn't help for the same reason.

Is it time to give up mail, and move all activities to web forums? I'd hate that.

PS: Yes, hanging in Vodafone's hotline to get them to resolve that issue.
PPS: Terminating the contract takes some time.

Update: Vodafone's technical support claims, this issue would not be their problem:

OpenRBL, SpamCop, Spamhaus, TQM³, NJABL, CBL, UCEPROTECT

Wow! That's what I call customer orientation.

New Year

A new year started, let's see if it can match the last one.

It did a good start with finally bringing new anti-smoking laws into action. It was an really embarrassing situation, that you had to choose between entering a restaurant/cafe/ice-parlor or keeping your health. It was annoying that you had change clothes immediatly after leaving such a place. What gives smokers the right to dictate, which places non-smokers can enter? What gives them the right to injure our bodies? It's just sad, that Berlin's authorities don't have the guts to ignore a shrill minority speaking against that laws and give keepers another transitional period of six months. That's unfair towards the non-smoking majority, it's unfair towards the staff in such localities. This laws are known for several months now - that was enough of transitional period! Well, but what to expect from a senat, were even the senator of health smokes...

No Privacy for FOSS Developers?

Benjamin, thank you for ruining this year's Chrismas days for me. I know, you didn't do this intentionally, but I have really bad days since I am aware of the privacy strip each Free Software developer does due ill-considered "services" like ohloh.net.

I don't want anyone to do statistics about FOSS contributions. Those stats make me feel naked. What follows is some longish explaination of my feelings regarding such "services", those not interested should just skip to my proposal.

Also I do not like the stats at ohloh.net, because they draw a very incomplete picture of my FOSS contributions, when you search for my real name. The only way to change this, is registering at ohloh.net, and associate all my shell accounts. I don't want to register at any random web community, just to force them to publish accurate information about me. I don't want this, as it costs my time, and I don't want this, as it restricts my freedom by accepting their terms of use.

What makes people believe they are allowed to do such stats? Simply the fact, that this information is available without much effort? Drastically spoken, it's also not much effort to break into houses, or to commit homicide - does the little effort make this actions legal?

A though argument to counter my fears is "but Google does similiar things for years, and nobdy complains". Really hard to counter, and haven't really found good words yet - so just some sketchy keywords: Websites are public by purpose, and their Google Groups archive is controversial. Actually - when checking for its name - I couldn't even find it anymore from their front page.

I need to resolve this privacy issue for me, as it dominates my thoughts for days now. That dramatically, that I came to insane ideas like revoking any FOSS contribution I ever made, or like starting a service like ohloh.net, that also publishes inaccurate information, but requires monthly fees for correcting information. Yes, those ideas are close to insanity, but maybe they help to understand which harm, services like ohloh.net do to me.

I started contributing to Free Software projects, since I like to improve my tools, since I working on exciting code. I never contributed for turning into a person of public interesst - like services in the style of ohloh.net obviously assume.

Well, enough of whining, let's figure out how to address the problem.

One possibility I see for not getting listed on sites like ohloh.net would be using your copyrights to add a message like this to all of your ChangeLog entries and commit messages:

The information associated with this change shall only be used for
improving and distributing this software. Any other use, like doing
statistics for instance, is not permitted.

I don't know if this works, as I am no laywer. I also agree that it would be quite ridiculous, to have this message assoicated with each commit. Instead I suggest formalizing our AUTHORS files in the spirit of our MAINTAINERS files:

 Mathias Hasselmann
 E-Mail: mathias hasselmann gmx de
 Userid: hasselmm
 License: code-only

Licence would contain a list of permissons:

I hope this post helps my upset brain's to move focus away abit form this topic now - Chrismas days are comming, damnit!

But also I hope for some constructive feedback, without getting flamed to much for my differing opinion regarding sites like ohloh.net.

Aren't Tomboy Notebooks redundant?

Boyd, don't you think that notebooks are redundant for an application that got tags already?

(Sorry, for commenting on PGO, but appearently you disabled comments for people without blogger.com account.)

libepc 0.3 released

A new version of the Easy Publish and Consume Library has found its way on GNOME's FTP servers.

This release has seen many API changes to make the library more versatile. For instance streaming capabilities and support for ZeroConf bookmarks have been added. Also noteworthy is the new service monitor, which provides a very easy method for finding libepc (and DNS-SD) services.

To see the ridiculous long list of see the NEWS file.

To download, visit http://ftp.gnome.org/pub/GNOME/sources/libepc/0.3/.

Totem Playlist Sharing

To test versatility of libepc I've written a Totem plugin for sharing the current playlist.

Screencast of the Plugin

Seems we've got another cool feature now, and libepc is in much better shape. Code is commited to Totem trunk, and also depends - surprise - on libepc trunk.

Disclaimer: Yes, demonstrating features of a media player without any audio track sucks, but Istanbul 0.2.2 hangs after recording with sound, and when running its pipeline with gst-launch I get alot of warnings about missing audio data plus some unpleasant, stuttering video.

Car Broken Open

This morning I had to find my car broken open. Since coming back to Berlin one year ago, this is the second time, some asocial bastard damaged my car. Its not even a new or expensive car. It's a trusty, 15 years old Vectra. What has happend to this place?

Is is time to leave this city of criminal and unemployed people?

Crap. Berlin's online police station also is offline: Maintaince work. No phone number, no address of the next police station in the phone book. F* world. Maybe I should just use the emergency number? It is an emergency - at least mentally.

Mathias, with one “t” (and “h”)

Btw: There are several spellings for the name my parents gave me, and I've got this variant:

Mathias with one “t” (and “h”)

I don't know why my parents have choosen this variant. People really seem to have problems with it. Every time someone writes it down, I have to explain the spelling: “Oh, just one 't', please” - “But with an 'h'?” - “Yes, with 'h'.” Nevertheless really I prefer my spelling. It looks much better to me, than Matthias or Mattias. Maybe I just prefer being Matze, instead of Matt. Don't know.

PS: Just learned, that “Matze” is the Yiddish name for some kind of Jewish bred, btw. Ok, would have to add some accent sign to get their pronounciation: “Mátze”. Wow. Incredible, what you learn by ranting.

PPS: Well, and I really hesitated to write this, but guess it has to be done - before I entirely loose my given name.

Re: g-thread-cancel

Richard, I'd really like to answer you, and this is the second time I'd like to do that, but unfortunatly you do not allow comments on your blog.

Well, before my karma reaches unknown depths let's add some real content to this posting:

I don't really know, why that function is missing, but my guess it, that randomly killing threads is quite dangerous, as threads share the process with your program. Stopping the thread at some random point most certainly will leave your entire program in an inconsistent state.

So common suggestion for stopping threads, is adding explicit cancelation points to your thread. Something like the following.

volatile gboolean running = TRUE;

static void* my_thread (void *data)
    while (running) do_work ();

void stop_thread (GThread *thread)
    running = FALSE;
    g_thread_join (thread);

Disclaimer: Don't take that code too verbatim. I absolutly hate threads and try to avoiding them when possible.

Btw, thanks to the genius fork() syscall, processes are dead cheap on *nix platforms. They are much more secure than threads. Specially if you think you have to interrupt them them.

Use gtk-doc to find required package version

Usually I am quite unsettled when adding package requirements to README files and configure scripts. AI never really know if the version I specified is correct.

This morning I had enough of this uncertainness and hacked a short Python script to extract that information from our find gtk-doc manuals: gtkdoc-check-symbol-versions.

Libxml2 cannot parse the HTML gtk-doc generates, so the script reads the gtk-doc manuals line by line, throws regular expressions at them and puts the matches into a hash table. When finished it reads the files it shall check, strips comments, splits the tails into words and looks up the minimum package version for every word.

Maybe the gtk-doc guys can bundle this (or a polished version of the script) with their package.

Usage is like this:

$ gtkdoc-check-symbol-versions \
  -p glib -p gobject -p libsoup -p gnutls -p gtk */*.[ch]
gtk-2.6 required for gtk_combo_box_get_active_text in examples/consumer-ui.c
glib-2.4 required for g_markup_printf_escaped in examples/consumer-ui.c
glib-2.6 required for g_option_context_new in examples/list-resources.c
gobject-2.4 required for G_DEFINE_TYPE in libepc/consumer.c
glib-2.10 required for g_slice_new0 in libepc/dispatcher.c
glib-2.12 required for g_hash_table_remove_all in libepc/dispatcher.c
gtk-2.10 required for gtk_window_set_deletable in libepc-ui/entropy-window.c
glib-2.14 required for g_timeout_add_seconds in tests/framework.c

What!? I need glib-2.14 just for g_timeout_add_seconds in the regression tests? Crap, I better change this.

Simple description of libepc

Seems I failed to give a simple description of libepc. People still ask what it really is.

Well, its nothing fancy. It's really just a public hash table.

Sounds trivial to implement, but isn't.

At least the discovery part: Current DNS-SD APIs provide a robust state monitoring API, and evilly also expect you to use it - were you just want a simple publish and forget API.

The easy to use hash table on top of HTTPS (server-side, client-side) really isn't that hard to do. Mainly an API design challenge. HTTPS - instead of D-Bus or XMPP or plain TCP/IP or whatever holy gral - was choosen for purly pragmatical reasons: Libsoup is a reasonable platform library, providing many of the features we wanted (encryption and authentication).

You believe libepc should use another transport mechanism or have other ideas? Well, I am writing about libepc to get feedback. One interesting point came from Havoc Pennington: He seems to believe this public hash table service should be shared by the entire desktop session, instead of setting up hash tables for every application.

Easy Publish and Consume Library

As GNOME remembers the meaning of the 'N' in its name, more and more GNOME applications become network aware. GNOME provides excellent libraries for implementing network capabilities, nevertheless quite some effort is needed to glue them together to provide a smooth user experience.

When starting to add network support to Glom, we at Openismus decided it would be time to stop this frequent reinvention of the wheel, and put some of this glue code into an easy to use library. So the Easy Publish and Consume Library (libepc) was born.

The Easy Publish and Consume Library is intended to provide an easy method to

When using that library you shall not bother about boring details like properly using Avahi or setting up SSL/TLS certificates. All you should do to let your application publish information to the network, is writing the following three commands:

publisher = epc_publisher_new ("Easy Publisher Example", NULL, NULL);
epc_publisher_add (publisher, "Hello", "World!", -1);
epc_publisher_run_async ();


Once you have done this, your application runs a HTTPS server, announcing itself to the local network via DNS-SD and publishes the information World! under the key Hello.

Retrieving values shouldn't be harder:

consumer = epc_consumer_new_for_name ("Easy Publisher Example");
value = epc_consumer_lookup (consumer, "Hello", &length, &error);


As those examples are working now, we Openismus guys would highly welcome some feedback - I even added e-mail notifications to my site to allow real discussion.

Well, maybe it should be noted, that libepc isn't meant to replace desktop configuration daemons like GConf or Ryan's dconf initiative. This library just is a simple method for publishing byte arrays and maybe UTF-8 strings to your network. No support for integers, booleans, no schemas. It's fully up to you, how to use the data published.

This locations at taschenorakel.de are just temporary locations, if nobody disagrees I'd like to upload this library to the GNOME servers as soon as possible.

Linking to library.gnome.org

Recently the brave gtk-doc guys introduced a tool called gtkdoc-rebase, which updates external links in your API docs to point on the GNOME Library. The gtk-doc.make script has been updated to run gtkdoc-rebase on make dist. Unfortunatly all this pretty stuff doesn't work out of the box on Gutsy, as two premise have to be fulfilled to make this voodoo work:

Updating all the gtk-docs I've got would have been a boring task. So I wrote a little script which updates the uncompressed index files, when documentation exists in the GNOME Library:

Use it carefully, as it sends HEAD requests to library.gnome.org for every gtk-doc package not having that <ONLINE> tag yet.

Did I mention already, that this script processes uncompressed index files only? So call sudo gunzip /usr/share/gtk-doc/html/*/index.sgml.gz before using it.

Playing with Reinteract

Found Owen's Reinteract Demo on Planet GNOME this morning and had to play with it immediately:

Reshell and Reglade

Source code: reshell.py and reglade.py.

Update: Some Steve asked for PIL support in Reinteract. The reimage.py module supports PIL images, GDK pixbufs, GTK widgets and file names. Screenshot.

iconv transliterations

This is a lazy web request.

In GNOME world we use the g_convert, which conveniently wraps the iconv library, to convert between character sets. A feature I considered quite useful was the builtin transliteration support: When adding the "//TRANSLIT" suffix to the target character set's name, iconv shall try to convert characters not present in the target charset to their most reasonable equivialent. For example "Schlüssel" should become "Schluessel" when converting from UTF-8 to ASCII and "доброй вечер" could become "dobroj vecher" (assuming the cyrillic input method of GTK+ works reasonably). This should be tested:

$ echo Schlüssel | LC_ALL=de_DE.UTF-8 iconv -t ASCII//TRANSLIT -f UTF-8


$ echo Schlüssel | LC_ALL=en_US.UTF-8 iconv -t ASCII//TRANSLIT -f UTF-8


$ echo доброй вечер | LC_ALL=de_DE.UTF-8 iconv -t ASCII//TRANSLIT -f UTF-8
?????? ?????
$ echo Schlüssel | LC_ALL=C iconv -t ASCII//TRANSLIT -f UTF-8


Seems the transliteration support of iconv is highly locale dependant.

So I ask a the lazy web: Are there functions in the GNOME stack allowing locale indepentend UTF-8 to ASCII transliterations?

Facebook and friends

On the school yard all the cool kids smoked.

I don't smoke.
I don't do Facebook, GMail, and friends.
I hope you see the link.

More elaborateled: I've grown up in a country having big brother organizations like the Stasi. They were wrong. The fact that big-brother-like organizations are run by private entities those days doesn't make them more more accurate. I reject Web 2.0 - if it means establishing Stasi-like organizations.

Doubts about voice chat

Voice Chat: Andrew, please no! I am one of those persons getting very distracted by people talking in the same room and I am one of those nasty guys requesting fellows to take a cigarette break (even if they do not smoke), when they start lenghtly discussions. Also you should consider, that written English seems much easier than talking for non-native speaker. Specially if you consider the heavy accent some native speakers have. Well, and you don't want to know how often I do dictionary lookups on IRC chats even today...

No, voice chat is no good for software colloberation - I guess.

Canvas Review

As announced by Murray already I am working for Openismus now. First task I got assigned was providing patches for some binding glitches in GooCanvas. Seems I complained too much about GooCanvas' code during that task. So Murray asked me to review GooCanvas, HippoCanvas and libccc to figure out which canvas would fit best for diagrams and reports in Glom.

As we have that nice canvas overview on the GNOME Wiki already, I added additional information to that wiki page. Thank you Emmanuele for updating the clutter records, btw.

HippoCanvas dropped out quickly for lacking printing support and more importantly for its boxed, HTML/CSS like layout. This approach doesn't seem to be flexible enough to support things like table relationship diagrams.

GooCanvas seems to be the most complete canvas, but it has some issues:

By provinding a function to pass a custom cairo context to the rendering routines its does only the trivial part of printing, but leaves pagination, which is the hard part of printing, to its users. Pagination usually is not trivial as you have to avoid splitting text lines and pictures on page boundaries:

Borken text due improper pagination

Techniques to avoid this glichtes include moving of short paragraphs and pictures to the next page, cutting paragraphs and text at cell and line boundaries, rewrapping text and rescaling pictures. I could not find hooks for doing this in GooCanvas, so when using GooCanvas for Glom at least the hooks for such features would have to be added to that canvas.

As it seems grid fitting is implemented for tables only. This causes a blurry and unprofessional look. It also lowers rendering performance as unnecessary antialiasing and resampling operations have to be applied.

Demonstration for pixel alignment

GooCanvas currently also has problems in its code architecture. Its data model structures are all public which puts quite some burden on maintainers willing to provide a stable API. This can be fixed easily as most/all of the fields exposed are be accessable by getters and setters.

A more serious problem is the optional model/view split which causes huge amounts of code duplication in GooCanvas. Currently GooCanvas gives you view items and model object, which in fact just are containers for the very same model data structure. View and model objects provide the same set of properties and methods to manipulate that shared data structure. This obviously is wrong: When there are view and model objects, all the model data should be stored in the model objects. At least there shouldn't be separate model data structures. The view objects should reference their model objects. But even that approach would be too complicated in my opinion, as in my opinion the canvas items itself are the model and the canvas, cell renderers, ... are the views. When the items have to store view specific data this issue should be handled internally (and not exposed to the user). I am pretty sure this change would reduce the lines of code GooCanvas needs by at least one third.

libccc is quite similiar to GooCanvas, which is not very suprising considering both want to provide a cairo based replacement for GNOME Canvas. libccc puts high emphasis on creating clean API and modern programming techiques. Usually this is a good thing, but considering the shear amount of other projects Sven is working on, it also directly leads to the biggest problem of libccc: Although being much older than GooCanvas 1), libccc has still lists "work in progress" for many features.

It is ahead of GooCanvas with its clean model/view separation. Beside the mandatory canvas widget the libraries provides additional view implementations like a GtkCellRenderer or a camera item (picture-in-picture). In addition to the features of GooCanvas it provides inline text editing and moves the burden of grid fitting from the canvas items to the views.


Without requiring printing support and high quality (pixel aligned) rendering the choice would be simple: Take GooCanvas, as it seems to be more complete. When if its feature matrix fits your needs, it's most reasonable to use this canvas widget.

Things shift when you figure out that you have add features. In that case GooCanvas' unnecessary code complexity hurts. You have to choose between investing alot of time on working with that complex and fragile code or convincing Damon (and the other people on the mailing list) of dropping the optional model/view split first - which also would need quite some time. Considering my weak mailing list discussion skills I'd most probably choose finishing libccc, instead of wasting that time on discussing and refactoring GooCanvas - but that's my personal opinion. People with better mailing list skills and better contact to Damon probably will vote different.

1) In opposition to common believe libccc really was started before GooCanvas. Sven demonstrated me libccc on 20C3 which was held in 2003, whereas GooCanvas was started in 2005.

Dear Kids

Dear Davyd and Anonymous: I really hope you guys grow up one day and realize something must be wrong with your attitude when you react on slight critism with words like "Politely, please go eat a dick" or "It's like a murderer hating to see the police, sry...".

Update: I took the "vegetarian" out the title, 'cause I do not indend to blame this group of people. I am just upset about the strong word Davyd and that anonymous person used to insult me.

Spell Checking for the Masses

Recently I needed spell checking support for some cairo (and Pango) based canvas widget. Should be easy to pick, considering there are several aproaches to implement spell checking for GTK+ widgets, like gtkspell or libsexy. Unfortunatly those pretty libraries have the fault of focusing on one single widget only. So equiped with the power of Vala I wrote some small generic spell checking library for GTK+. Instead of directly attaching to some widget this library uses a simple interface for adding spellcheck support:

using GLib;

namespace Gtk {
    public interface SpellCheckClient {
        public abstract List<SpellCheckCluster> get_clusters ();

        public abstract void reset_highlighting ();
        public abstract void highlight_word (SpellCheckCluster! word, 
                                             int start, int end);
        public abstract void replace_word (SpellCheckCluster! word, 
                                           string! replacement);

        public signal void changed ();
        public signal void populate_popup (SpellCheckCluster word, 
                                           Menu! menu);

As the result the library supports spell checking for several GTK+ classes now: GtkTextView, GtkLabel, GtkEntry, GtkTreeModel and PangoLayout.

Spell checking itself is provided by Enchant.

Update: Forgot to demonstrate the multi-lingual mode. Updated the screen cast. It works similiar to Evolution and gtkspell3: A word only fails if it isn't found in any dictionary and some of the menu entries are modified to contain - in violation to the HIG, but in lack of a better idea - submenus. Also forgot to mention future plans: For text views it should be possible to selectivly disable spell checking for read-only or code sections. Also it should be possible to retreive a section's language by inspecting Pango attributes of the text. Well, and finally I have to properly package the beast.

Automake support for Vala

Using Vala together with automake was quite painful so far. When looking into libvala's Makefile.am for instance you'll see alot of duplication.

So I hacked a little script generating the automake rules needed for vala code. After adding the vala-support script to your autogen.sh script your Makefile.am can look as simple as this:

lib_LTLIBRARIES = libtest.la

libtest_la_CFLAGS = $(AM_CFLAGS) $(GTK_CFLAGS)
libtest_la_VALAFLAGS = --library=test --pkg=gtk+-2.0
libtest_la_LIBADD = $(GTK_LIBS)

libtest_la_SOURCES = \
    test-first.vala \
    test-second.vala \

include Makefile.vm

Unfortunatly this is not integrated into upstream automake yet - simply because I am not very skilled in reading other people's Perl code - but the vala-support script itself is written in Perl already, so it should be easy for some skilled Perl hacker to merge that code into automake.

So anyone there to take that task?

Final SoC-Status

So the summer of code has reached its hands-down phasis and few minutes before the deadline finally height-for-width support has landed:

Height for Width Support in GTK+

Proper support for rotated labels with ellipses also has been backported to GTK+:

Rotated text with ellipses backported.

Well, but end of Summer of Code doesn't mean end of hacking: Have to teach GtkHBox and GtkTable the size-for-allocation trick. The icon view could profit from exposing such information. Well, and finally the extended layout branch has to be merged into GTK+ trunk, which currently is feature frozen.

Guess this Summer of Code was quite some success for me: Implemented some useful features and finally managed to fully join the GNOME community.

SoC-Status 2007/08/02

I didn't provide a status report for some time, so what happend in extended layout world?

I stopped to waste time with baseline alignment and switched to spreading natural size support over GTK+. As a result of this effort many widgets and one cell renderer are providing and interpreting natural size information now: GtkAlignment, GtkBin, GtkButton, GtkCellRendererText, GtkCellView, GtkFrame, GtkHBox, GtkLabel, GtkSocket, GtkTable and GtkVBox.

When working on GtkVBox and vertical natural size aware alignment in GtkTable I realized GtkLabel doesn't support ellipses when rotated. So I implemented ellipsizing support for rotated labels. This code only works properly for angles being multiples of 90° so far (first screencast), but I managed to write some test program getting ellipses right for any angle (second screencast) - just have to adopt the code to the label.

Completly unrelated Teemu Ikonen reminded me of my common file format chooser project. So I moved the code from Bugzilla to libegg. Finally I also figured out how to automatically integrate that widget with file choosers. So I added file filter synchronization and automatic file extension appending (third screencast). The code still is quite rough. Icons should be retrieved via the MIME type API of GVFS. Nevertheless it would be nice if interested parties would verify if it works for them in principle. Change requests should be posted in Bug 440431.

Rotated labels with ellipses are broken still Testing how to rotate ellipsized labels The new file format chooser

Liquid Bomb Complot

Luis, there was no prevented assault involving liquid bombs in London. There just are airport owners who want to force you to enter their overpriced "duty free" shopping malls. ;-)

At least that's the idea I had when waiting for my flight on Nottingham East-Midlands: My brand-new water bottle was thrown away at the security check, after the check there was only one shop offering water for a price of £ 3.20 per litre. The waiting area was full of shops and noisy. The departure monitors wrote "relax and shop" for pending flights. Relaxing was impossible at that noisy place. The shopping part made me angry considering the insanly high price level of that area.

Disclaimer: Don't take this theory too seriously. Most certainly there really was a prevented assault, but the effects of this prevented assault just are not acceptable for me. This "enhanced" security checks take forever, cause paranoia among flight guests and security personal. Well, and finally I am pretty sure they will not protected me from being killed by a terrorist. If the flight checks are too restrict, terrorists will target other public transportation vehicles to reach a high body count.


Uch, it's almost a week ago, that GUADEC 2007 ended for me early. Appoligies for those of you I've meet, but could not say goodbye on Thursday - I had to get my flight back home. This goes especially to Federico and Phillip. After meeting many GNOME people in person, I know even more than I knew before, that GNOME is the community I belong to. Once again its an interessting experience of hearing your voices in mind, when chatting with you on IRC. Micke: Nice that Sven was able to introduce you to Jürg - I completly forgot my personal schedule when we talked.

Dominant topics of this GUADEC were desktop bling and web integration. I am all for the bling. Regarding Web integration I have some reservations. Maybe I am too old to get Web 2.0. Maybe I am too paranoid to trust Web 2.0. Lucas brought it to the point: Web awareness is neccessary, but turning GNOME into a fully web-dependent online desktop is absolutly pointless: No need to build free software, when you plan to replace Microsoft with Google (even if Google seems to play nice so far).

Also wondering, that Web 2.0 enhusiasts are that exited about the possiblities to transfer their data from one provider to another. Over that exitement you overlook, that web based services take you away one very important freedom: The freedom to delete data. Google even is proud of havining no delete button in their mail client. Speaking of web mail clients: Could you Google-Mail fan boys stop trying to annoy us local mail users in your doomed attempts to convince us of that concept as beeing the Holy Grail, please? Boys, web interfaces for mail are around since the web exists. Guess they are some of the oldest services! Probably older than search engines. So if people prefer local clients over web clients they have reasons. Examples for unsolvable problems: Privacy and latency (even with AJAX).

So lets come to some talks. The following words are very critical. Seems to be my nature. So do not forget: I absolutly enjoyed that GUADEC!

Havoc: Before your talk I feared you smart guy were hit by a brick, when starting to talk about GNOME Online Desktop. Now I admit you have a point: Let's be faster than proprietary vendors this time. Nevertheless some of the problems you described are artificial and caused by your special live style. People do not get new devices every few weeks - so your configuration synchronisation problem seems to be artificial - expect maybe for contacts. Well, and being in a situation, where your notebook turns into a brick when being offline, is nothing to be very proud off.

Alex Graveley: Incredible demo, you should have reserved more time for it - as you tried to fill your talk with an incredible amount of ridicilous claims. In German I'd say: "Nicht alles was hinkt, ist ein Vergleich". First of all you do not seem to get priorities right for free software development: First priority is freedom. Fame comes after that. You (and your beloved Firefox project) seem to reverse those priorities. Well, and when you claimed "Web developers are free software developers", you absolutly ruined your talk. At least I feelt like having to throw tomatos and eggs at you, when that slide showed up. From my observation a very dominant majority of web developers will never ever show you the backend code of their sites. So how can those guys be free software developers - despite that the use free software? Well, and sharing HTML code on the web is by accident. Guess a very large number of Web developers would prever to encrypt their HTML and CSS hacks. Just want to mention this large ammount of "Show-Source-Code" prevention hacks developed for the Internet Explorer. So - despite Pyro being an incredibly cool technical demonstration - that project is based on a wrong premise: Web developers would care about libre software.

SoC-Status 2007/07/02

Extended layout ScreencastLast week I wanted to implement something to show, so I started on baseline alignment. First lesson I've learned: The original idea, of just changing the vertical position of the widgets turned out to be thought too simple. Instead of applying the baseline adjustments from the outside by tweaking the widgets GtkAllocation, I have to tell the widgets which offset they should apply to their baselines to produce a proper offset. This was easy to implement for GtkLabel - despite all xalign and xscale hacks in that widget. What bloat we have in GTK+, that a simple label widget has to consume more than 4500 lines of code!? On propagating those baseline offsets through simple GtkBin, especially GtkAlignment widgets I've cut my teeth. So I dedided to take a break from baseline alignment and implement natural sizing. Results of my efforts can be watched in the screencast. Well, or in the extented-layout branch of GTK+.

Stripping down GNU make

After reading Thomas' rant about automake 1.10 rejecting GNU-makeism in its script I wondered if it wouldn't possible to ship GNU make with all tarballs, instead of all the autotools crap. So I did some experiments this morning.

Raw GNU make 3.81 as distributed by the FSF requires 1.1 MB. After unpacking 6.4 MB of disk space are used:

 576     config/
1052     doc/
 140     glob/
2028     po/
 556     tests/
 168     w32/
2080     .

Considering the goal of distributing GNU make with each of your tarballs, quite alot of space is used by non-essential stuff like unit tests, documentation and translations. Removing the doc, po and tests folder produces a much smaller tarball:

-rw-r--r-- 1 mathias mathias 541323 2007-07-02 07:50 make-3.81.tar.bz2

That's already smaller than the configure script shipped with make 3.81 (takes 456k) and the m4 macros used to generated it (576k). Encouraged by this, I became even more radical - I removed the autoconf stuff:

-rw-r--r-- 1 mathias mathias 364566 2007-07-02 07:53 make-3.81.tar.bz2

Well, but this steps leaves you without any platform detection for the build system. So some replacement would be needed. Tried with bulldozer some time ago, by injecting pre-conditions and checks as rules into my GNUmakefile. Worked with few code. Maybe worth to start a library of GNU make based platform detection rules?

Conclusion: Avoiding GNU-makeisms in automake scripts is absolutely pointless, because:

  1. GNU make is available for any platform your software supports anyway.
  2. The core of GNU make is that much smaller than the usual autoconf/automake bloat, so it could be shipped with every tarball to make up the build system.
  3. Its only a matter of time, until Greenpeace shows up and blames the free software community for wasting insane amounts of electrons.

SoC-Status 2007/06/28

During the last week I've adding GtkExtendedLayout support to GtkLabel and GtkBin. GtkVBox got some first code to use this extended layout information. Results are not that fancy yet, but the next days should bring some nice break-through.

The test program got rather confusing with all the guides drawn, so it got checkboxes to toggle visibility of certain guide types. When hovering a widget, the widget itself and its guides start blinking.

Completly unrelated: Peter Sikking posted on gtk-devel today, to introduce his ideas for tag based printing dialogs. Meet him already at the LinuxTag and I absolutely liked his mockups (despite looking quite raw). He suggests to tag printing options instead of randomly spreading them over notebook pages. When opening the printing dialog, you choose tags fitting your current task ("Quick Printing", "Handouts", ...) and get presented all the relevant switches. No more searching for the page holding duplex options and such. Tags are proven to be efficient to organize information. So I definitely consider Peter's concepts being worth to consider.

SoC-Status 2007/06/19

Here comes a new Summer of Code status report.

Update: Learned from Federico and Matthias Clasen, that they usually comment out large parts of gtk-docs.sgml when doing documentation, well and that partly the Docbook stylesheets are too be blamed for the poor performance as they do alot of O(n^2) stuff.

Saving Bandwidth with git-svn

git-svn is a cool tool to have the joy of local branches and git's outstanding performance, whilest working with a Subversion repository. Unfortunatly git-svn has the disadvantage of wasting insane amounts of bandwidth when cloning a Subversion repository: Cloning for instance the GTK+ repository costs serveral gigs of bandwidth - just do end with about 200 MB of compressed data on your disk. It's told this happens due a bug in Subversion's language bindings the godfathers SVN did not care about yet - although patches exists.

Having just 5 GB per month to waste, this big appetite is a real problem, but fortunatly I realized how to deal with it:

  1. run git-svn clone on a machine with cheap internet connection, like for instance your virtual web server.
  2. call git repack on the cheap machine
  3. let rsync transfer the compressed repository to your home

This also should work for relocating a git-svn repository, when the URL of the SVN repo changed.

Update: Eric Wong - the maintainer of git-svn - has patched Subversion packages for Debian.

SoC-Status 2007/06/07

No much progress on my SoC project: This year the LinuxTag took place in my home town Berlin, so I helped out at GNOME booth there. Nice opportunity to meet some GNOME people. Tim Janik told me about some height-for-width traps - looks like I have to extend my unit tests. Talked with Rob Taylor about some document centric usability improvements for GNOME. Sven Herzberg enlightened me, that I want to use GNOME Launch Box. Took a birds-eye view on Bug 347883 which was bugging Michael Natterer for some time and fixed it intermediatly. It was interesting to see how accustomed visitors of LinuxTag are to GNOME.

Got distracted from GNOME hacking by the forced server switch for taschenorakel.de. Took the chance to setup a django based blog. Also got distracted by Bug 440431: Needed that kind of widget for my Photobuch software.