I have spent the last weeks trying to improve some parts of GHangtux. One of the improvements (the more obvious and complicated one), came with the code restructuring.

BEFORE, all the code was divided in three different files:
- main.c: all code for the program except for the keyboard widget.
- keyboard.c/.h: keyboard widget code.

This structure made the code easy to read at the very beginning, but was obviously a bad idea for the long term. Actually, you should always divide your program in small modules although you think is going to be a very tiny one. It might be now, but who knows what is going to happen in the future. Also, you help to make this code reusable for other programs or programmers. So, mental note: always use modular code from the beginning!.

NOW, the code is divided in ten different files:
- ghangtux.c/.h: main program and definition of main structures.
- ghangtux_ui.c/.h: user interface.
- ghangtux_management.c/.h: functions for game management.
- ghangtux_utils.c/.h: auxiliary functions.
- ghangtux_keyboard.c/.h: keyboard widget.

After all the new code structure was ready, I decided to set up GTK-Doc to document GHangtux in a proper way (still need to finish commenting the functions), which brought me to the eternal discussion "recursive or non recursive Makefiles?". GTK-Doc documentation gave me the impression that I HAD to use recursive make with no explanation and no other chance. After some research and discussing about it with Dave, we found the way to do it "my way", that means: non recursive. You can read Peter Miller's excellent paper to learn why recursive make invocations are both slow and error-prone.

Happy with the results so far, I moved on to "convert GHangtux" to gtkmm, so now I am busy reading "Accelerated C++" and "Effective C++". Let's wait for the magic to happen soon ;).

Take care!

Sigi is now in her fifth month of our second pregnancy. During our last scan we learned that it will be a sister for Liam. He’s already looking forward to her arrival. We feel lucky that we will have both a boy and a girl.

Her due date is almost exactly the same as last time – at the start of January. I’ll then be generally unavailable to the world for a few weeks, gradually reappearing as our routine settles down.

• Openismus day 60: Learning M4 as it seems useful for autotools and C++/*mm bindings. ION, BBQ at Openismus office on Friday 27th, August. #
• Openismus day 59: Looking into cluttermm_tutorial problems which is leading me into learning more C++-binding stuff, which is fine with me. #
• Openismus day 58: Got cluttermm building in jhbuild by adding atkmm dependency. Had to use gtkmm's gtkmm-2.22 branch. Needs 2.24 branch? #
• Openismus day 57: Started porting gmemory to use gtkmm. Got autotools stuff converted. Couple minor issues with jhbuild and *mm stuff. #
• Openismus day 56: Got emacs configured nicely now. Dropped CEDET for now. Currently using autocompletion, xcscope gccsense, flymake. #
• Openismus day 55: My look into gmmproc turned into me spending more time setting up emacs. Issues getting semantic to find system libs. #

It was raining outside, and suddenly also inside. That’s nothing new – normally I can blame my windows for that.

But this time the reason was platform-independent:
It’s one of the (unused) network cables.

Hello again GNOME !

I’ve been back for a few weeks now from taking a month vacation in Mexico with my girlfriend; heres a courtesy picture of us standing on top of the world… or at least on top of a pyramid

… and the great news is that I’m continuing my employment with Openismus GmbH indefinitely, working specifically on GTK+ and GNOME.

So let’s recap on what’s been going on in GTK+ height-for-width resizing land since my last post.

Out of the patches that were available on the GTK+ native-layout branch, we landed the work on GtkExpander allowing the expander labels to wrap but still havent finished the work on wrapping text inside treeviews.

Similar to the GtkExpander implementation, we added support for wrapping/ellipsizing text in GtkFrame label widgets (to see this all in action you can try the ./tests/testheightforwidth demo from GTK+ git master at any time, I wont include shots for the GtkFrame here as it works pretty much exactly as the expander does).

So instead of running full till into another revision on the GtkTreeView height-for-width patches I took a different approach and moved right along to implement naturally sizing GtkComboBox (which we landed in GTK+ git master last week).

Some might wonder what is the relation between combo boxes and treeviews. The key point here is that they both end up using GtkCellRenderers to render content; the combo box by way of the GtkCellView widget. Since the cell renderer modifications for height-for-width GTK+ was a huge patch; implementing GtkComboBox first was a good excuse to pull that work in first and hopefully simplify the work that needs to still be done for treeviews.

So without further adieu here are some shots of how the combo box is performing in height-for-width land:

So far not too much to observe, the above combo box renders the liststore with a wrapping cell renderer, the combo box below renders the same liststore but uses ellipsizing cell renderers instead.

For the wrapping renderer, you need only specify the “wrap-width” which will be used as a minimum width request, if no “max-width-chars” was set on the cell renderer then the renderer will request the fully unwrapped text width as a natural width.

For ellipsizing renderers, you just specify the ellipsize mode and again the renderer will try to request the full text width as a natural size.

In this (above) shot we see the text unwrap fully when the combo is allocated sufficient space to display the underlying cell renders (and similarly the lower combo box need not ellipsize at this size).

And finally, at their smallest possible size the cell renderer text wraps up to the minimum width which was specified by the user/programmer via the GtkCellRendererText:wrap-width property.

Well once I got that far I thought it would be enough… until I clicked on a streached out combo box and found that the menu items were still requesting the height for the minimum cell width instead of the height for the menu’s allocated width (imagine a menu with random looking menuitem heights and text that doesnt quite fit the vertical allocation).

So we went on to implementing the natural size allocation in GtkMenu and the coresponding requests in GtkMenuShell:

Note in this screenshot some menu items wrap while some dont wrap, however they are all allocated the correct height.

Here at the minimum width all of the items are wrapping and they still get allocated a correct height.

And with combo boxes doing height-for-width requests.. finally we were able to close this nasty bug.

Enjoy ! … and stay tuned for another episode of wrapping/ellipsizing text in treeview widgets

• Openismus day 54: Rereading the gmmproc documentation slowly. Doing the example is good excuse to reacquaint myself with Emacs. #
• Openismus day 53: Committed code for glib-mkenums changes. Began looking into updating cluttermm. Gotta learn to wrap libs sooner or later. #
• Openismus day 52: Learned about glib-mkenums and implemented most needed changes. Remember emums != enums . Finished http://is.gd/efGXH. #

So I decided to finally upgrade from Karmic to Lucid. Easy task, only should take some time: After all I did a plain default install. Well, ok - I've used the alternative ISO as my employer requires me to use full disk encryption. It's a good idea anyway, no idea why this feature isn't the default for all installs.

So after some time the install finishes, the computer reboots and grub the kernel tells me it cannot find the root fs.

Obviously nobody cared to check if upgrade with encrypted disks works. Too boring. Still would not have happend with some professional OS vendor. Especially not four mounths after the initial release.

EPIC FAIL! Thank you. Not.

Update: In case you need proof for "too boring" check this rotting bug report.

With the release of Rygel 0.7.3 I thought I should bring up some sort of FAQ for Rygel and especially the MediaExport plugin, since it has some features and behavior changes that might lead to confusion for long-time (and new) users:

Plugin concurrency

With the release of 0.7.4 you cannot enable both tracker and MediaExport plugins at once. If you do so, the MediaExport plugin will be shut down in favor of the tracker plugin.

Meta-data extraction

Speed

Since 0.7.3 Rygel now uses the gunp-dlna package for meta-data extraction. This is based on the gst-discoverer work by Arun and Edward from Collabora Multimedia. It is significantly faster on video files than the old home-grown meta-data extraction stuff.

Filters

Rygel no longer blindly tries to extract meta-data from everything it sees in the directories. Instead it uses a positive list of file extensions to include. In the default configuration these are:

• Audio formats
  .mp3, .oga, .ogg, .mp4, .flac, .wav, .wma
• Video formats
  .ogv, .ogg, .mkv, .avi, .mp4, .mpeg, .mpg, .ts. .wmv, .asf
• Image formats
  .jpeg, .jpg

If your favorite format is missing, don’t hesitate to file a bug

Folder hierarchy

Since Rygel 0.5.2 there has been support for user-defined virtual folders in the MediaExport plugin. It allowed the user to browse through his media by artist and album e.g. With Rygel 0.7.3 the possibility to define those folders yourself is gone. The configuration syntax wasn’t really intuitive and easy to get wrong. We defined a set of build-in folders which resemble the folders provided by the Tracker plugin.

And since the addition of this default folders made the view of the root folder even more cluttered, I decided to move all every non-virtual folder that directly corresponds to a file-system folder into its own subfolder. In an upcoming release a configuration option to disable the display of this folder will be added.

If we missed out a folder you really need, please file a bug for it.

I updated the windows ports of gssdp and gupnp today, did some further clean-up on the gupnp port and filed merge-requests for both on gitorious.

I also deleted the gupnp-win32 repository on github. New development will go to this repository on gitorious. There is still the gssdp-win32 repository on github since I have not yet taken care of the MSVC additions.

I also started wrapping gssdp et al into *mm (hey, I work for Openismus now but this has proven to be somewhat difficult.

This year was my first time at GUADEC, and it was just great. I have got to chat to people involved in the GNOME shell, usability and accessibility programs and got in touch with the members of the "Gnome Women"  group as well. But not everything was chatting and socializing. I attended several interesting talks as well: clutter, state of union, GNOME shell... and joined a very handy workshop about "Design thinking" by the hand of the Invented Here guys. Pheeww, I am still trying to process all the new information!.

Back to chatting and socializing, more fun came at the evenings with the Canonical Party (first GUADEC where people danced I have heard), Collabora barbecue and the hackfest at Revelation Space.

Big news during GUADEC?
-  The release of GNOME 3.0 have been pushed back to March 2011, but at the same time, The GNOME Project will ship GNOME 2.32 in September, along with a preview release of GNOME 3.0. Several distributions will ship GNOME 3.0 components that can be used for user previews or developer testing. 
- An announcement was also made about the location for GUADEC 2011. Applause for Berlin this time!.

This year the Openismus crewed surprised all attendants with our new "Sommer/Autumn 2010 T-shirts collection". All thanks Kat.

I know..., envy is the word you are looking for ;). Hopefully I get the chance to go to GUADEC again next year.

Fine days for C++ and Qt coders, well, the experienced ones:

openismus is looking out for you as well!

Looking out for you to join our team creating quality and fighting entropy. It’s a chance to work on serious projects with (sometimes uncompromising, ahem) colleagues at Openismus who care about getting things done properly.

Please email Murray if you are looking for payed work and can show some public involvement. He likes having URIs for blogs, ohloh, git/svn, mailing lists, etc, to see your personal sense of code quality and your ability to communicate. We ideally need people who can work in Germany, probably moving to Berlin.
(We do GTK+, gtkmm, and Qt development, and we like really knowing them all and more. These days Maemo/Meego developers need a wide range of experience.)

Get a first impressions what your potential colleagues are alike on planet openismus. Want to be among us? Jump!

• End of Life for Maemo5 hildon-desktop & friends.
  Being honest and communicating that something is dead: New, and good.
  On the wishlist for next time: Announce it on the developer mailing list (though that implies interaction with people outside of Nokia, scary!) in case somebody wants to pick up maintainership.
  Unlikely, but still.
• If you want to file bug reports about user interface and platform component issues in Maemo5: It’s welcome in case of major issues. Otherwise save your time and efforts as unstable development happens in MeeGo Handset which has its own bugtracker awaiting your bug reports. MeeGo Handset can be run on an N900 if you love to live on the edge.
• Quim Gil on Maemo5 Licensing Change Requests.

• Openismus day 51: Mostly distracted by Andre's beautiful pony tail and conservative rhetoric. A little secret about Andre.. He eats tofu. #
• Openismus day 50: 50 days at Openismus. Woot! Started looking into glib-mkenums. Read half of http://is.gd/efGXH. Other stuff I forget. #
• Openismus day 49: After problems with clutter-gtk on Fedora, I decided to install Ubuntu. Reran Valgrind. Now I get no definite leaks. Hmm?! #
• Openismus day 48: More memory leak analysis w/ Valgrind. Mentioned some definite leaks that I can't seem to find. Did fix a few, though. #
• Openismus day 48: #
• Openismus day 47: After taking care of some paper work, I started using Valgrind's Memcheck tool to find leaks in gmemory. #

We slept in the new flat for the first time last night. As usual, at least in Germany, it’s going to take a few weeks to get DSL connected. In our case, DSL gets connected on the 30th. This used to be the time when I’d fall into a deep depression due to withdrawal issues. However, this time is different.

For the time being I’m using the awesome new feature in Android 2.2 for sharing a mobile internet connection. Impressed with how easy it is to set up. It’s as easy as turning the feature on and setting the access point name and passphrase. Once that’s done up to 8 computers can connect as they would to any wireless access point.

Unfortunately, my mobile data plan only allows up to 200MB at 3G speed after which it gets throttled down to GPRS speeds. But it’s better than nothing and once DSL is finally connected we’ll be rewarded with 50Mbits down and 10Mbits up. That’s about 8-9 faster than what we had in San Diego for only a little more money.

Version 0.1.1 of Cagibi
Release often and early! Hadn’t done so with Cagibi, the experimental cache/proxy system for SSDP, for a while, as I was only experimenting. But with the upcoming 4.5.0 release of KDE’s fine products (the platform, the workspaces and the apps), I rushed 0.1.0 as a first version which was basically working, to be used by the network:/ kio-slave (included in the runtime part of KDE’s platform). Well, basically working in my test environment. But not for the first brave packager who gave it a try, ouch.

So time for version 0.1.1 of Cagibi!
New in this version is basically only the fix for the D-Bus service description file, which now points to the right location of the daemon executable.
There is now also an initial pkg-config file, but it seems pkg-config is just for libs, not D-Bus-only services.

The 0.1.1 tarball can be downloaded from stable/cagibi at the KDE ftp server (please consider using one of the mirrors).

network:/ kio-slave freezes kded of KDE’s platform 4.5.0
But there was more, more bad news: the network:/ kio-slave will freeze kded, a central daemon of KDE’s platform, without and with Cagibi. This bug only got discovered during the creation of the platform packages for 4.5.0, so the fix will be only included in 4.5.1, unless your packager/distribution backports it.

Workaround until 4.5.1
Yet there is a workaround for you if you don’t mind some config file editing. Open the file `kde4-config --prefix`/share/kde4/services/kded/networkwatcher.desktop in your text editor and make this changes:

# This line needs to be added
X-KDE-Kded-autoload=true
# This line needs to be commented
#X-KDE-Kded-load-on-demand=true

This will make kded load the module networkwatcher already at the start, so the deadlock caused by the on-demand loading can be circumvented.

Now, still with KDE’s platform 4.5.0, this workaround and Cagibi 0.1.1 you must make sure that the Cagibi daemon is already running before kded (and the networkwatcher) starts, if you want to also have UPnP devices/services listed, as delivered from Cagibi. So e.g. hack the startkde script to start cagibid in the background pretty early.
Best please just wait for the 4.5.1 version of KDE’s platform and Cagibi 0.1.1 to be available as packages.

UPnP support also for EFL
In related notes I just saw that still alive’n'kicking Enlightenment (rumored to now be used by Samsung for their mobile devices’ platform Bada, well, looks like) now also has a library to wrap around UPnP, named Eupnp. Another candidate to make use of Cagibi as central SSDP cache/proxy daemon

Lots of activity on the maemo.org wiki as always (except for GUADEC when I was not editing, although many other people were). I have been mostly doing tidying of the Documentation articles, which involves making the code examples human-readable (not an autogenerated mess of HTML formatting), adding markup and fixing broken links. There is still a lot to do, but progress is good.

Elsewhere in the wiki there have been many changes to pages regarding the N900 hardware subsystems, so look out for more in this area from Joerg rw and Speedevil.

• Openismus day 46: Finished autoconf changes to fix install issues in gmemory. Bungled first push. Commit here: http://bit.ly/cRpibS #
• Openismus day 45: Back to work after 2 days of moving into new flat. Started cleaning up autoconf problems. Added –enable-warnings flag. #
• Openismus day 40-44: GUADEC! #

Today I had a failing fsck during Ubuntu startup: any HDD activity would simply stop when the check claimed to have reached 89% Couldn't abort, had to cold start the box. Same result. OK, abort the check, bypass it and see what's going on. If only! Ubuntu thinks it is a great idea to drop normal users into maintenance mode. Once you leave maintenance mode, the check starts again! Same result. Did it occur to anyone that the check itself might be at fault sometimes, and that a userfriendly way to bypass this check is absolutely crucial?

(If fsck had a better reputation for finding real problems instead of being the root cause for many data losses, and if the ext4 version wasn't written by mr-lossy-file-systems-ftw himself, then perhaps I'd be worried. I am not. Fsck offers little protection if you don't have a real backup anyway. So the best advice is really to disable any automatic fsck checks.)

So – A year has passed, two Ubuntu versions, what’s the state of MTP vs. mass storage? Apparently still broken. Same same but different.

Instead of making the player crash, gphoto2/libmtp and usb mass storage fight for the right to access the device which leads to very ugly errors in dmesg that look like the device or at least its file-system is severely broken

So, once again: Either make the device MTP only or remove the device’s entry from the libmtp udev rules which now reside in /lib/udev/rules.d/45-libmtp8.rules

Arrived in Amsterdam on Jul 22. First person I bumped into was Marc-Andre, fun. Already saw more of that city in one afternoon than I managed during the Maemo Desktop Summit in 2009.

Enjoyed trip to House of Bols on monday, Holland House Improved FTW (you won't find it on their website). Free shots got me squiffy. Bought passion liquor (let's hope Jon is trustworthy).

Met the trainees later the day and went to the Hague. Nice city, not as crazy as Amsterdam. Liked the sea side + grote markt.

GUADEC itself was great. Should have looked into the user-centric-design workshop I guess, but missed the one on monday, and the other overlaped with a talk, oh well. ClutterSmith looks fun. Compared to how you'd have to use Qt's graphics view + state machine framework, to get something similar, I prefer the tool-based approach that hides all the boring code from me, but allows me to focus on the transition logic.

MX and St are thinking about a remerge, that's a good thing. In overall, GNOME Shell looks a lot more promising now.

Let's see whether we can make GUADEC 2011 in Berlin as good as this one.

We asked our 3 trainees to do some little projects to make sure that we ironed out any problems in their C knowledge before moving on to C++, to get them familiar with autotools, and generally to have code to talk to each other about.  I forced them to make actual tarball releases, so they can also complete features as if there were real users, instead of just hacking without focus. These are the modest results. Click on the links to see the descriptions and screenshots on their blogs.

Jon Nordby’s massifg: To show graphs from valgrind massif output. So far it only shows the simple graphs, though using the Cairo drawing API makes printing to PDF easy, so it’s already useful. I want Jon to do the detailed graphs too, but I’ve asked him to look for a proper Graph API first, because it’s tedious to do it all with just Cairo. Hopefully without acquiring awkward dependencies. He’d welcome advice.

Chris Kühl’s GMemory: One of those games that lets you turn over tiles for a moment and try to find matching tiles. It uses clutter and could probably be a candidate for the gnome-games package soon.

Patricia Santana Cruz’s GHangTux: A hangman word-guess game in which Tux the penguin loses his accessories rather than his life.

(The Gs in the names were their idea.)

I think they have all learned lots from the exercise and are ready for the next stage.

As part of a bigger project of mine, I wanted to answer the following questions: How can one tell which physical port a hotplugged usb-device is plugged into on Linux? Can one do this when the device is plugged into an usb-hub (i.e: non-root hub) too? Since this is potentially useful to others out there, I share my findings here.

The usual “lsusb” or “lsusb -v” gives no indication that the kernel knows about the physical topology of the devices connected to an USB bus. However “lsusb -t” does indeed show the topology, so the kernel does know about it and make this info available to user-space. So, how to use this in udev? Prodding some USB storage class devices with udevinfo, shows that there is no attribute that gives this information directly. But, the DEVPATH attribute for USB devices actually contains this information.

For instance, an USB mass storage device connected to port 2 of the root-hub with bus number 2 has the following devpath: “/devices/pci0000:00/0000:00:1d.7/usb2/2-2/2-2:1.0/host12/target12:0:0/12:0:0:0/block/sdb” and a USB mass storage device connected to port 5 of the root-hub with bus number 1 has the devpath “/devices/pci0000:00/0000:00:1d.7/usb1/1-5/1-5:1.0/host5/target5:0:0/5:0:0:0/block/sdb”. It becomes a bit confusing when there are USB hubs involved: “/devices/pci0000:00/0000:00:1d.7/usb2/2-1/2-1.1/2-1.1.1/2-1.1.1:1.0/host16/target16:0:0/16:0:0:0/block/sdb” refers to a device plugged into port 1 of an USB hub plugged into port 1 of a second hub which is plugged into port 1 of the root-hub with bus number 2.

We see that in all cases the information about the physical topology is in the substring just before “:1.0″; “2-2″, “1-5″ and “2-1.1.1″, respectively for the given examples. And that the format is “$busnumber-$port” for the simple case of connecting the device directly to the root-hub, and $busnumber-$port1.$port2  ->   .$portN for the general case, with N-1 usb-hubs between the device and the root-hub.

Just to show that this works, here is a quick and dirty udev rule and helper python script which parses the devpath and creates a symlink to the first partition of a USB mass storage device under /dev/usb based on the bus and port the device is connected to. Results might look like this:

tree /dev/usb/                                                                    Thu Jul 29 17:34:38 2010

/dev/usb/
`-- 2
    `-- 2
        |-- 2 -> ../../../sdc1
        `-- 4
            `-- 4 -> ../../../../sdb1

A more useful thing to do might for instance be passing through all devices connected to a certain physical usb-port to a certain virtual machine. Or maybe letting an embedded system responding differently to USB devices plugged into a physically secured root-hub than to one that is available to the user.

The talk (at GUADEC).

Apart from the usual Release Team service announcement and its charming follow-up street fights and the two short Bugsquad and Localization reports at the AGM meeting I also had the pleasure to present a talk about something that I’ve been thinking about for a while:

Identifying software projects and translation teams in need

My theory in short: We lose people that attach patches in Bugzilla to dead modules and never get a response. We waste time translating/localizing modules that will never see a release again. We are stalled as we have always been around 50 “supported” languages for the last GNOME releases. And we need ways out of all this.

For those who could not attend my talk and for further investigation, its slides (pdf/odp), data (cvs/odt) and code (sh) are available. The hardest part really is to find the meaningful data in all that noise. While I plan to continue thinking about this any input is welcome.

The translations (L10N).

For the translations part of my talk, as a first step the Releases Comparison table could get a neater URL and another column that calculates the difference in coverage between the last two years, plus linking the entries in the Languages column against the corresponding teams (yes, teams). Teams that lost more than 10% coverage in the last 2 years are: mk, dz, sq, si, ne, en_CA, cy, hr, fa, vi.
Another data source are those languages with no Git activity (0-2 commits in the last 2 years: an, bal, bem, dv, ff, fur, gn, ha, km, ks, ky, nap, tg, yo, zh_trad, zu; 3-20 commits: en_AU, ha, kk, la, ug).
Contacting these drowning translation teams / maintainers in order to ask for problems or if they still have enough time could for example be handled by the Coordination Team.

In case of no response a translation team can be considered dead.
Now one could take a look whether some contributions exist in damned-lies by people that could be interested to become the new coordinator. And/or downstream teams could be contacted and asked whether they are interested in contributing in upstream GNOME, e.g. teams in Fedora, openSUSE, Ubuntu or other distributions.
While becoming the new translation team coordinator is usually handled quite quickly on gnome-i18n mailing list once it is clear that the old coordinator is not around anymore, changing the assignee data in GNOME Bugzilla and getting Git commit access usually take a bit longer and could currently be demotivating bottlenecks. Time to review the rules or to have a survey about this?

The modules (Git).

For the modules part of it, two warnings could be added to Bugzilla, damned-lies and when checking out via Git for those modules that have not had much activity lately in GNOME Git.

Maintainers of modules that have not seen any commits for a long time (two years?) could be contacted to get a statement about the module’s status (this was done in the past already with mixed results). In case of no answer or a negative answer this could mean “Note: This module is obsolete or abandonned. No work is planned to take place and you might waste your time by filing a bug report or attaching a patch here”.

If we don’t know (yet) this could mean “Note: This module has not seen much activity in the code repository lately” (plus a hint what to do). Of course this first needs a definition for time period and commits thresholds in order to define “not much activity lately”. This could warn patch contributors in Bugzilla to either be patient for a patch review or to contact the maintainer first and it could help translation teams to set priorities and not to translate inactive modules. Another email contact should be provided (probably not the release team but a new team in GNOME?) for the potential case that the maintainer does not respond. However technically I don’t know where the Git activity results could be cached in order to not continiously be queried by several other parts of GNOME’s infrastructure.
As written before, comments, ideas and criticism are welcome. This is still an early stage.

GUADEC (In general).

And to talk in general about GUADEC: As usual it felt like holidays but I finally managed to not spend the entire day at the conference venue in order to also see a bit of the city (like the ICJ, the Scheveningen beach and the city center on Saturday). It was great to have my girl with me and to meet with old and new colleagues of the Openismus crew. And I had interesting chats with Amir H. Moin about datamining and the Evolution crew about non-coderelated stuff, both while lying on a beach couch.

MassifG is an application for visualizing the output of valgrinds massif tool. I am writing it as part of my trainee program here at Openismus. MassifG is free software, available under GPLv3. You will find the git repository at gitorious, and the tarball release for 0.1 here. Packages for Arch are available in AUR.

Used together with massif MassifG gives you a nice, simple graph of allocated heap memory over time which you can use to help evaluate if your program is leaking memory or not:

Current status

With release 0.1 MassifG can:

• Parse and display a simple graph from massif output.
• Open files selected on the command line or from the UI.
• Print out the graph to a printer or file. This code was contributed by Murray Cumming – thanks!

I was hoping that I could make version 0.1 the “minimally useful” release, but I have to admit that it is not quite there yet. Instead I nickname release 0.1 “getting it out there”. The main issue is that there is massif output that breaks the graph, see under tests/ for an example.

Implementation

MassifG is written in C, and uses GTK+ for its graphical user interface. Once the ability to export the graph is implemented, it should be easy to allow the application to build and run without GTK, if anyone wants to do that.

The parser is a simple state-machine. It might have been wiser to use bison+flex, and I’ll reevaluate that when I need to implement parsing of the detailed output.

The graph functionality is implemented using Cairo and Pango. While Cairo and Pango are excellent technologies with nice APIs, they are quite low-level and that means having to care about all the details. As that brings no benefit to this application I might rewrite the graphing functionality to use the goffice library instead. Sadly there seems to be little high-level or introductionary documentation to goffice APIs, so I might have to fix that along the way.

Roadmap

In the short term I will:

• Implement parsing and graphing of the detailed massif output
• Fix the graphing bug(s)
• Add the ability to export/save a graph as PNG,PDF et.c. without having to go by the printing dialog

In the longer term I’m considering:

• Adding the ability to run massif on a program directly from MassifG
• An interactive mode which updates the graph while the program to be analyzed is still running
• Making a custom widget which other applications can embed

In the meantime, please do give the current version some testing, and report bugs and other issues.

Wondering, what I have been doing the last few weeks?. GTK+ is the answer, GHangtux 1.0 the result, and since we all know that a picture is worth a thousand words I go just straight to the introductions: "World, this is GHangtux, GHangtux this is the world".


What is GHangtux?
GHangtux is a free program variation of the popular Hangman game. It has been designed for people of all ages and has a simple, easy-to-use interface.

It provides a keyboard and a sentence/word to guess, whose theme, the player is able to select. Current themes are: films, objects and persons.

During the game, a graphic sequence of tux images will be displayed, indicating the player how many attempts he/she has left. 

How to "create life" from some code lines?
1. Getting familiar with GTK+. As I wrote in the last post, I spent my first weeks at Openismus learning GTK+ and to put this into practice, I worked in a very small but helpful project. "Foundations of GTK+ Development" was very useful in this learning process and gave me a good base.

2. Making and correcting mistakes. The next step was to learn about all those mistakes I made, to repeat them and to relearn from them again. This is part of every single step actually.

3. Testing the new knowledge. After the first two steps, it seemed that I was prepare to start my first simple GTK+ application which is the very early version of the game.

4. Creating a custom widget. After playing with GTK+ a few more weeks, I decided to create my own custom widget: the game's keyboard. For this step, I found Davyd Madeley's clock widget tutorial quite handy.

5. Integration of the custom widget in the early version of GHangtux. This is the last version of the game. 

What is coming next?
- Internationalization with i18n.
- More themes.
- More image themes.
- Shortcuts for the menus. 
- Others: clutter, desktop files...

"Side effects" of having developed GHangtux?
- Learning Git and discovering how powerful this tool is.
- Learning Autotools helped by Alexandre Duret-Lutz's tutorial, and some    Openismus manuals.
- Practicing C.
- Practicing Glade.
- Programming style.
- Improving my communication skills.

You can follow the project under the repository in GitHub or download it in .tgz or .zip.  All comments are welcome, as are merge requests.

Enjoy!

It’s 3 AM, GUADEC is big fun as usual, I’m in the hotel lobby, and as I have only seen one summary blogpost on planet.gnome.org yet I’d like to mention that GNOME 3.0 will be released in March 2011.

Good night.

What?
Cagibi is the prototype (in progress) of a cache/proxy daemon for SSDP (the discovery part of UPnP).
Starting with upcoming KDE SC 4.5 the network:/ kio-slave (from kdebase/runtime) will optionally use this daemon to also show UPnP devices/services in its listing of the local network: If the UPnP (root)device (e.g. a router or a media server like on the PS3) offers a web interface, the network:/ kio-slave will forward to that url on a click of the item in the listing.
(There is no build-time check for it in the network:/ kio-slave code yet, as well as no pkg-config support in Cagibi. It’s an optional run-time D-Bus dependency, if not existing just silently ignored by the network:/ kio-slave system)

Where?
Cagibi 0.1.0 tarballs can be downloaded from stable/cagibi at the KDE ftp server (please consider using one of the mirrors).

Why?
As the network:/ kio-slave so far only supported services as reported from DNS-SD/Zeroconf via the Avahi daemon on GNU/Linux (as wrapped by KDNSSD in the KDE platform), it was obvious to me that such a daemon approach should be also done for SSDP, both for listening to service/device announcements and publishing our own.
So far these FLOSS implementation of (parts of) the UPnP specs have passed my eyes, the UPnP protocol stack frameworks/libs

• Herqq UPnP (HUPnP) (Qt-based)
• BRisa (Qt-based in a variant)
• GUPnP (GLib-based)

the media servers

• MediaTomb (custom code stack)
• FUPPES (custom code stack)

and the stuffed UPnP device racks/server suites

Coherence (custom code stack)

Rygel (GUPnP)

Just, they all did the SSDP stuff inside a lib/the program itself, so in case multiple processes which are using that lib will be doing UPnP stuff, they will duplicate resource usage a little. Especially unneeded as there is usually already a daemon like Avahi running, which could do that.

It may be a small optimization, but IMHO still valid the work, e.g.:

• a cache is faster, you do not have to wait for the broadcast answers on the startup of your SSDP client, where answers might be late as in 3 secs
• the daemon as the only one interfacing to network regarding SSDP would run as system user with almost no rights, so exposing less of a risk
• no need to run a UPnP device server process all the time just to send the alive message once in a while (wakeup on port activity by inetd or daemon)
• would be a single network/cpu heartbeat instance for publishing alive messages for multiple local UPnP device offerings or receiving broadcast messages not interested in
• ?

And now?
If you are a packager, please package Cagibi and add it to your distributions, so at least users of programs built on the KDE platform >= 4.5 can also see UPnP devices in the KIO system and open their web interfaces.

If you are a developer of a UPnP stack module/lib, consider to use Cagibi as backend to your SSDP API. Even better, pick up the code and run with it, make a better Cagibi yourself, also adding the support for publishing. And even better, go for Avahi and beg for an extension for SSDP

If you are me, you make Cagibi for the next version install on the system bus, so the daemon instance gets used by all users on the device, also change description data in D-Bus API to a string map of variant data types for better backward compatibility, in the future

And if you have a comment, post it (or “Leave it”, like WordPress says)

While most of my fellows at Openismus are currently in The Hague for the GUADEC (after all those who are there are Gnome users and developers ) I got aware that this year’s edition of the conference for users and developers of KDE software, Akademy, is already a few weeks ago again, time to complete and dump my blog entry about it. (And time to welcome next year’s joint event, so all Openismus people will be at the same place at the same time ).

After more than two month with almost no work on KDE stuff (due to broken backlight on old laptop, starting as employee at Openismus and for this moving to and settling temporarily in Helsinki, getting a new shiny laptop but with completely broken kernel drivers for the GPU) I was happy to be able to dedicate my full time to KDE stuff again, by rushing some development setup onto the laptop I temporarily have for work and start hacking on the things that had been stuck over the recent month, especially with all the people around I need to talk to for that:

Okteta plugin to KDevelop
I had started that plugin at the Kate-KDevelop sprint this February. It was basically working already, but there was no way to actually trigger the loading of any file as byte array, and without any sufficient clues about the architecture and not much time to do the needed communication via email and irc this integration plugin just bitrotted in playground. Now with Alexander Dymo and Millian Wolff sitting just at one of the other tables I was a matter of preparing my questions for them (and solving part of the problem myself, as you do usually) and some little conversation, and done it was. The only showstopper are a bug in the KDevelop platform itself, worked on, and needing to wait for the SC 4.5 release next month, as only then the headers of the Okteta libs are published, which these plugin uses.

network:/ kio-slave
This kio-slave is part of the SC since 4.3 (in kdebase/runtime, try network:/), but since then lacking further polish and better integration with Places, bookmarks and the remote:/ kio-slave. At least one one of the biggest hurdles, the overbending of the KIO concepts, by introducing mimetypes for the service items (for a nice representation in the view), which on a click forward to a proper url of that service, which may deliver an item of another mimetype, but that is not expected.
I was lucky to find time slots at one of the clones of David Faure present who showed his deep code knowledge and quick solution ability. So starting with the RC3 the network:/ kio-slave finally starts to get usable and can be promoted a little more

Cagibi
Claiming that the network:/ kio-slave was just sitting there and lacking further polish is only telling half of the truth. Last october at a sprint in Barcelona with the nice boys from Coherence I did an initial implementation of a UPnP backend, so also the devices/services as announced within the UPnP system are listed in the network, at least their root device with a link to the device’s webinterface if present (presentation url).
Since then some time has passed, and as I needed only the SSDP part of UPnP for the network:/ kio-slave, running a feature-full daemon like Coherence was not the best solution, so under the name Cagibi I threw together some custom code for a prototype of a SSDP cache/proxy, as also once upon a time proposed by Armijn Hemel, the long-time pusher for UPnP support in KDE.
With Armijn present, I could demo it to him, so he could see first fruits of his (and Adriaan’s) sprint sponsoring efforts related to this. How and when you can see it (like in SC 4.5 ?), will be topic of the next post.

I also was glad to meet, amongst others I was glad to meet of course , Nikhil Marathe, who works to finally bring the UPnP mediaserver kio-slave into existence as his GSoC 2010 project, being mentored by Bart, who started on that during the sprints with Coherence. And so Nikhil can demo more fruits, and they look tasty. The days are counted at which you cannot access your files on your X-Box (or whatever closed system you have exposing a UPnP mediaserver) from Amarok, Dolphin or any KDE platform filedialog.

And I got a lot of inspiration from all the workshops, for going on with going Mobile, for getting our personal and open share in the Cloud, for linking our minds and data models with Telepathy, and what not.

This year’s Akademy was great, thanks again for everyone involved to make it happen as it did!

For the last few weeks I’ve been working on a small concentration game called GMemory. This was done as a part of the Openismus trainee program.

Update: See below.

For those not familiar with the game Concentration, or Memory as I grew up knowing it, the basic idea is that one has a number of matching card pairs turned face down. The player(s) then attempt(s) to match these pairs by turning over two cards. If the cards match those two cards remain face up. Otherwise, the cards are returned to the face down position. This is repeated until all cards are face up. Here’s a screencast of GMemory being played.

As you can hopefully see, GMemory is currently in a playable state and it actual quite enjoyable if you’re into these types of games. However, there is a lot more to do to reach what I’d consider a 1.0 release. Besides some code reworking and some known bugs, I’d like to see a score tracker, multi-player mode, card animation and selectable themes.

The game is written in C using GTK+, GObject, Clutter and Cairo. In the course of writing GMemory I ran into a few bugs in clutter-gtk. The first bug was that no events were being received when using the embedded clutter gtk widget. You can find the bug report here. The second major bug I ran into was that once I got a version combination that gave me events, I always received double the events that I expected. This is a known bug and I’ve got a work around in the code for that.

There are also a number of known bugs. As you may have noticed from the screencast, the last card of the last successful match does not get shown before the statistics dialog box pops up. It seems the dialog blocks the drawing even thought the function to draw the card is called before the call to show the dialog box. Another bug is that once the game is over the playing area does not resize when the window is resized. I’ll tackle this once I’ve reworked the code some.

You can find GMemory’s git repository at Gitorious and the tarball can be had here.

Unfortunately, right now I’m building against the master branches of clutter and clutter-gtk. Expect breakage.

Btw, right now.

Update: After trying this on Ubuntu Lucid, I experienced none of the event-related problems with clutter-gtk. This seems to be Fedora 13 specific. Thus, I’ve removed the workaround for the double event issue and changed the configure.ac file to rely on the clutter and clutter-gtk versions shipped with Ubuntu Lucid. The new tarball is here.

Tomorrow (Tuesday) I fly to Amsterdam and take the train to Den Haag for GUADEC 2010, joining 9 other Openismus employees: Karsten Bräckelman, Jens Georg, Ekaterina Gerasimova, Michael Hasselmann, David King, Andre Klapper, Chris Kühl, Jon Nordby and Patricia Santana Cruz. For Chris, Jon and Patricia, it’s their first GUADEC, so they are eager to soak up knowledge and will particularly enjoy meeting everyone.

This time Openismus is even sponsoring GUADEC to show our support, though at the lowest level because it’s already expensive enough to send 10 employees.

The T-Shirts are attractive and different again. Photos soon.

The fingerprint reader

The fingerprint reader is a mess. It has the USB id (147e:2016) of the upeksonly driver in the fprint project, but it doesn’t work. The reader seems to work with the normal UPEK driver (either in thinkfinger or fprint) by modifying the supported USB id. But the answers it presents to the driver don’t seem to conform to anything it knows.

• Openismus day 39: Today I'm releasing version 0.1 of GMemory. Ugly warnings still there but it's very playable. Enjoy. http://bit.ly/aWJ0sH #
• Oops. That last update should have read "Openismus day 38." I knew that would happen eventually. #
• Openismus day 37: GMemory now has colored shapes instead of just colors. Getting ugly warnings from cairo, though. First release tomorrow. #
• Openismus day 37: More GUI polishing. http://bit.ly/9D4kPc There's a small bug where the last card is not shown due to dialog blocking it. #
• Openismus day 36: Decided to do the GUI before animation. Got game controls working. Statistics and timer are now in status bar. #
• Openismus day 35: Got gameplay and resizing working pretty well now. Will tackle animation next, then the GUI. Code here: http://is.gd/dyKoj #
• Openismus day 34: Got GMemory actually working. I really need to do a redesign, but window resizing and animation are next. Oh.. It was HOT! #

In KDE SC 4.3 a searchbox has been added to Dolphin's toolbar. It used Nepomuk to do the searching:

or: You’re holding it wrong. Seriously. Once upon a time, you could buy a IBM/Lenovo ThinkPad with Intel graphics and it just worked. While the Intel issues in the last versions of Ubuntu were mostly home-grown, the current disaster with the Core i3/i5 on-chip graphics isn’t. Like in the X201.

The Ubutu experience

Getting Ubuntu 10.4 LTS to work on an X201 isn’t too hard. You just need to follow some simple steps:

1. Get Ubuntu (obviously) and put it on an USB stick; the X201 doesn’t have a CD drive
2. Go to http://people.canonical.com/~hzhang/554569/ and grab the latest kernel package linked there (see also Launchpad bug 554569)
3. Get the most recent BIOS update from Lenovo. A description on how to update your BIOS if you don’t have an optical drive may be found at thinkwiki.org
4. Go to the BIOS setup and deactivate Intel AMT.
5. Install Ubuntu normally. The installer should work just fine. If the graphical installer doesn’t, try the alternate install CD.
6. After the installation is done, boot from USB once again and go into rescue mode to install the kernel package downloaded before.
7. Boot normally.

Remaining issues

• External video
  VGA works, but if you shut down the machine with the external monitor connected, it will somehow lockup (CPU is busy)
• Suspend/Resume
  With the kernel from the launchpad bug, USB works after resume; the only thing I noticed is that sometimes the wireless LAN won’t come up again (like 1 in 10 resumes).
• UltraBase
  No idea yet. Haven’t used though it is said that there are still problems with the display port on it

gconftool-2 –set /apps/xchat/channel_list/auto_popup –type bool false

Over the last few days, I added a Backup feature to Glom. It’s in Glom 1.14.4 that I released today. I don’t usually add features to stable releases, but this time it might help some people.

The Export Backup menu item saves everything in a .tar.gz tarball, using PostgresSQL’s pg_dump command and tar. (I hate calling command-line utilities from code, instead of calling functions in libraries.) The Restore Backup command uses that .tar.gz tarball and recreates a Glom system, either locally or on a central server if you choose.

The backup feature is obviously useful in general, but it’s particularly important since we noticed that use of pg_dump and pg_restore is necessary for migration when upgrading PostgreSQL, for instance from version 8.3 to 8.4.That’s not so awful when you just have one central database server, and Debian/Ubuntu even have a script that does the pg_dump/pg_restore dance on your central data when you upgrade. But Glom’s self-hosting feature (the default) has a separate set of database files for each .glom file, starting the PostgreSQL instance on demand. Ubuntu’s upgrade system obviously can’t know about all those files, which might even be on a USB stick.

The Backup feature can be used to work around this problem, if you remember to use it before upgrading your distro, but it’s not a nice solution.

Before anybody tells me to use SQLite instead, please remember that it still doesn’t have the features Glom needs, such as access-control and multi-user network sharing.

Qt has had an open bug-tracker for a few months now. I am very happy about that. It has made life far more pleasant for Qt developers compared to the past. However, there are some problems. In summary, bug reporters are often treated like the enemy instead of contributors, and this could be fixed easily.

My company, Openismus, provides bugmasters to corporate open source projects such as maemo.org. We know how to make the best use of outside contributions, so enthusiasts stay loyal, and we know how to manage bug databases for the long term. See the overwhelmingly positive feedback for Andre and Karsten, maemo.org’s bugmasters. They acquired these skills while establishing  GNOME’s bug squad, working on GNOME’s huge bug database.

I have linked to some Qt bugs as anecdotal examples of poor interaction with bug reporters. I am not interested in a discussion here of the technical aspects of these bugs. They are not meant to be technically critical. Also, half of them are for QtMobility, whose developers are generally very helpful, but even they haven’t learned the best bug-tracker habits. I don’t think I have seen enough Qt bug reports to have a fully representative sample, but my short experience does suggest that there are serious problems. I don’t mean to exaggerate or be unfair.

Awkward UI

Let’s look at a random bug. This view (not this particular bug) will be the first look at the bug-tracker for many people, as they follow a link to an existing bug. But it does not seem designed for humans. There are some particular problems:

How do I add a comment?

Typically, I’ll read the comments on a bug report to see what’s happening. But then there’s no obvious way to add my own comment. If I look around then I finally see a “Comment on this issue” link nestled among other less important action at the left hand side. I believe that many people won’t find that link, or will be discouraged by the awkwardness. I much prefer just writing a comment right into a bugzilla page.

Noise

The “all” page is too complicated, with lots of machine-generated noise. Instead of fixing that, there are tabs that show reduced views: All, Comments, Work Log, Change History, Transitions. This makes the whole page seem even more complicated.

The all page is so nasty that many people will switch to the comments page. But then comments lose their context. For instance, here (bug 7303) the Qt employee seems to be blaming the reporter though he is really just talking to someone that he has assigned the bug to. I’d rather just see a single page, as in bugzilla, without so much noise. The notification emails are similarly padded with irrelevant details.

Rush to close

We notice a strong tendency for the Qt employees to close bugs at any cost for any arbitrary reason as quickly as possible. Presumably they are under pressure to reduce the simple number of open bugs. But a bug-tracker exists to collect information that can gradually be used to improve software. If you think of everything as short-term and rush to ignore that information then you will not make the improvements and customers will assume that you don’t care.

Hard to check the fix

When I close bugs, I mention at least the commit message that I used. Sometimes I link to the commit’s web page on our gitweb or gitorious. But Qt bugs are often closed with a mention of the git commit ID (such as d65d3becc292523f0962aac9d2bf7b96d9c47c04), with no link. For instance, bug 8865 and bug 5729. I am thankful for the fixes but, particularly for documentation fixes, it’s best if I can verify it and reply quickly.

Viewing the change for a particular commit ID is awkward, requiring lengthy use of the command line outside of the browser. Even the gitorious web site doesn’t let me search for a commit ID, so I have to browse through pages of recent commits using the browsers find-on-page feature.

Actually, the person fixing the bug often cannot provide a gitorious web link at that time because that commit isn’t even public yet, because Qt’s gitorious repository is just a mirror, updated approximately daily from a secret repository. Things would be easier if they just worked in an open repository. In the meantime, Qt’s bug tracker should be hacked to recognize and link commit IDs, showing a “try tomorrow” page if the commit is not yet public.

Not supported. Not public

If the Qt developers decide (after the fact) that something in Qt is not supported then the bug may be closed, instead of leaving it open for someone to fix. But if something is not supported then it shouldn’t be in the release. For instance, bug 7334.

There’s also lots of Qt API that is used widely but not documented. Bug reports about the lack of documentation may be closed instead of leaving it open for someone to fix. But all API should be documented for the sake of implementation quality, regardless of whether it is public. And if API shouldn’t be used then its documentation should say that it shouldn’t be used.

Closing bugs because they require work

Bugs are sometimes closed because they would require effort to fix them. This makes no sense to me. Even if no Qt employee plans to fix them, they should stay open so others can fix them, and so that the information is kept in one bug report, with repeated reports being marked as duplicates. For instance, bug 5915.

Sometimes the idea of necessary work seems to be invented just as a way to close a bug. For instance, in bug 5729, a simple patch is not enough. The reporter is told that he must test it on multiple platforms, ignoring the possibility to test the harmless change widely during regular unstable releases.

For non-employees, the page even has some probably-unintentional machine-generated “You don’t have permission to work on this issue” at the left, just in case the reader didn’t feel unwanted enough already.

Out Of Scope

Likewise, if the Qt developers don’t personally see a problem as their priority then they will sometimes close it as “Out Of Scope”, regardless of whether the reporter cares about it or whether he might provide a patch.

Sometimes (bug 5729 again) this happens without the Qt employee even writing a comment explaining why. This is the bug-tracker equivalent of “Go away. We don’t want you to use our software”. Stopping this should be a top priority.

I’ve also seen one case (bug 6074) where this was used when the Qt developer meant “already fixed”. Until I asked for clarification (most people don’t) I assumed that they just didn’t care.

Can’t reopen bugs.

If a fix is not good enough, or the Qt employee has misunderstood the problem, I can’t reopen the bug. That is very frustrating. Most people will not beg for the bug to be reopened or even bother continuing to comment on the closed bug. Luckily we do have the option to submit gitorious merge requests when our bug has been incorrectly closed. For instance, bug 11496.

Can’t close bugs

There’s also no way for external contributors to close bugs. So Qt gets no outside help with bug triaging. This arbitrary separation between employees and external contributors is an obstacle to open development.

Tristan has been doing some challenging work for us recently, working on Glade, the GtkToolPallette, and finally finishing off the extended-layout improvements to GTK+ that Mathias Hasselmann started for Google’s Summer of Code in the days when he had free time. The extended layout fixes several user-noticeable problems in applications, making it easier for UIs to adjust properly to different screen sizes without hacks. It’s hard detailed work in lots of code, requiring Tristan’s methodical approach.

I hope that this will also allow some new types of container widgets. He might work on that when he’s back from Holiday in August.

Anyway, this post is just to say that Tristan has agreed to work with us for the foreseeable future so we always have someone with time to work on things like this.

There has been lots of activity on the maemo.org wiki recently. Over the last few weeks I have merged information from the documentation hierarchy into the developer guide, cutting lots of duplicate content. I added redirects so that people following links from external sites will not see blank pages. There has also been plenty of the usual tidying, including adding links and reformatting to make the wiki a nicer place.

Also of note is the large contribution from Magick777, who has been making some great edits to add information regarding migration from an S60 device and lots more.

• Openismus day 33: Started implementing actual game play functionality for GMemory. Followed up on Fedora clutter bug: http://bit.ly/b7sz3M #
• Openismus day 32: Got randomization and basic layout completed for GMemory. Commit is here: http://bit.ly/a4pnos #
• Openismus day 31: Ran into quite a few problem with my card layout and randomization code. Had to learned a good bit about gdb and GList. #
• Openismus day 30: More work on gmemory. implementing randomize and layout. Read section two of http://bit.ly/bdRVsU #

• Openismus day 29: More good progress on GMemory. Learned signals in GObjects and how to track down segfaults with gdb. http://is.gd/dm5J9 #
• Openismus day 28: Made good progress on gmemory. Had to rearrange my classes after rethinking things. Code here: http://is.gd/dl84O #
• Openismus day 27: Followed up on yesterday's bug, finally got back to programming. Got stuck on a segfault. Still looking for the cause. #
• Openismus day 26: Tracked down the proper combination of package versions to get things working. Bug report here: http://bit.ly/b7sz3M #
• Openismus day 25: Finally got my first clues to my clutter problem. Seems Fedora packages are broken. My be graphics driver, though. ?? #

Thanks to the work of Dariusz and Alban we now have P2P via Telepathy for Miniature.

Maybe it's worth to notice that we use Maemo's contact chooser here, and that it blends perfectly with our Qt application (we still have some crashes on our side though). Nice job from the Fremantle team! there!

If you try the receipe shown here with a RTSP source, you might need to throw in an additional input-selector element in your pipline.

• Well, it seems that the gtk_clutter_embed examples work fine in Ubuntu 10.4 but not Fedora 13. I'll have to look into why that is on Monday. #
• Openismus day 24: Still looking at gtk_clutter issue. Didn't get much done due to heat & lack of sleep. Fell asleep on a beanbag. #
• Openismus day 23: Ran into issues with gtk_clutter_embed and events. Clutter-only code works fine. Affects Openismus clutter tutorial, too. #
• Openismus day 22: Went much deeper into clutter and GObject. –The devil's in the details.– Very basic clutter-derived GObjects working. #
• Openismus day 21: Setup basic UI, started boilerplate code for clutter-based playing area and card gobjects. Then, BBQ! #
• Openismus day 20: Familiarized myself with Clutter and how to use it within my game. Decided not to use Glade/GtkBuilder for main window. #

Meeto! Eh… Me too! Just a train ride of less than 2 hours away, and with travel and accomodation for the full week happily sponsored by my employer Openismus

Having dropped from KDE development for the last two month, I still have all my plans and hopes for future work at least on Kasten and Okteta So I am looking forward to meet old and new KDE fellows in Tampere and to talk about how to make our hardware, small and big, a better tool to use.

These last weeks I’ve been working on finishing the remaining bits of the height-for-width layout system for GTK+.

The GtkExtendedLayout interface, which has recently been renamed to GtkSizeRequest has been merged into GTK+ recently with only some basic features leveraging the new code (the new GtkSizeRequest interface allows widgets to trade height for width when negotiating their geometry, read this informative post for more details on how this works).

I’m going to be putting a branch together to be reviewed but here’s a sneak preview of what’s been added in height-for-width land.

Wrapping expander labels:

When the expander is allocated something smaller:

At it’s smallest size:

Ok ok I know expanders are not that exciting… I’m only posting them cause the screenshots have pretty colours in them…

Naturally sizing Tree Views

Ok this is the juice, as you might guess working anything new into the treeview code is … some kind of nightmare… so first the easy part… here are some ellipsizing cell renderers packed into some columns in a view to show how it naturally sizes:

And when you shrink it:

Wrapping Cell Renderers in Tree Views

Ok heres the wild stuff, first of all I have to say I’m not very proud of all the cute kittens I had to slay to get this done… that is to say that there is an interesting new problem for scrolled windows that parent height for width widgets that may result in deadly feedback loops that lockup your desktop… thankfully I found a trick to avoid it. It’s not that pretty and in the long term the hack should be replaced… with… well with something generally more kind to your kittens.

All that said… it does work and calculate row-height for width asynchronously in the background and only when columns are set to resize etc etc… hopefully this wont be much of a performance hit for views that handle large datasets.

The above shows the treeview at its full width; it’s packed in a scrolled window with automatic scrollbars.

When you shrink the view the row heights will be recalculated and redisplayed, the horizontal scrollbar of the scrolled window will only appear if the child view is allocated less than its minimum possible width.

This particular view can be resized very slim, just because the minimum width-chars of the renderers are not set and so they are all permitted to get pretty small:

While I’m happy to have got as far as wrapping text in treeview’s; that was only the hardest challenge of the GtkCellRenderer brand – after this there is still more to be done for GtkIconView, GtkCellView and consequently, GtkComboBox.

And of course, all of this fancy cell renderer stuff is going to have to pass review and all… but we’re getting there !

And I’m proud to say that all these recent developments have been brought to you by Openismus GmbH.

Enjoy !

• Openismus day 19: Fought a battle to get intltool integrated with autotools. Was victorious in the end! See commit: http://bit.ly/ahVlWb. #
• Openismus day 18: Setup project skeleton using Autotools: http://bit.ly/9Q49wV. Started setting up project for i18n using intltools. #
• Openismus day 17: False start on new project. Wanted to integrate with GNOME games, but decided to start from scratch. Read autotools tut. #
• Openismus day 16: Read first chapter of http://bit.ly/9z7X1q. Decided on Gtk+ app to work on: "Memory" game such as http://bit.ly/bq5ZXO #
• Openismus day 15: Met Murray for the first time. Talked about progress & what to expect going forward. Fixed small issues in Gtkmm and Gtk+. #

Having attended last year’s GCDS keynote one sentence in the latest GNOME Foundation board meeting minutes scared me: “GNOME.Asia/COSCUP: Richard Stallman will be doing a keynote”.

As I was told that he has received a copy of GNOME’s new Speaker guidelines I still have some (naive?) hope left that people have learned something in the meantime. Time will tell.

Announcing another maemo.org Bugday:

Wednesday, June 30th, 16:00-00:00 UTC
in #maemo-bugs on Freenode IRC

No specific topic set – take a look at our wiki for some ideas.

Bugdays are about hanging out together on IRC, triaging/discussing some reports in maemo.org Bugzilla, and introducing new people into triaging. No technical knowledge needed, no obligations. Step by and say hello to the Bugsquad or become part of it.

Quick update of the list of modules (not necessarily complete) that do not yet work with GTK3.

• Note: The table does not cover porting apps to use both GTK2 and GTK3.
• Tickets with background color are blocked by missing GTK+ API.

	GSeal	Deprec. symbols	GTK+ modules
bug-buddy			to do
epiphany		to do
gdl	to do	to do
gdm	to do
glade3	to do
gnome-panel	to do	to do
gnome-screensaver	to do
gnome-terminal	to do
gnome-utils	to do
gtk-engines	to do	to do
gtk-vnc	to do (fixed in git but needs new tarball)
libnotify	to do (fixed in git but needs new tarball)
libslab	to do
libwnck	to do
metacity	to do	to do
raptor		to do
swfdec	to do
vinagre	to do
vte	to do

For a longer list of issues remaining for GNOME 3, take a look at Bugzilla.
Also Migrating to GSettings is required and not covered by this table.

• Openismus day 14: Got to work at 6:10 so I could watch afternoon matches. Finished up menus & actions, made actions contextually sensitive. #
• Openismus day 13: Made some changes in yesterday's commit after input from Murray, fixed a silly logic bug and started with menus & actions. #
• Openismus day 12: Still learning gtk+ API. Focused on GtkTreeIter and GtkComboBoxEntry today. Git repo here: http://bit.ly/bu7uHi #
• Openismus day 11: Got a simple GTK+ app working to a point where I could push to my Gitorious account. Learning the GtkTreeView API mostly. #
• Openismus day 10: Actually started writing code; simple gtk+ stuff. Got my jhbuild configuration down to ~60 modules instead of ~260. #

Some projects on gitorious want all patches via git merge requests. This is very tedious, particularly for small changes. It’s therefore likely that many small improvements will never be submitted. Projects must care about that if they care about quality.

As far as I can tell, you must do it like this:

Create a remote clone

You can do that via the project’s top level web page. For instance. Then you need to “checkout” that clone on the command line.

Or reuse an existing clone, though you’ll have to rebase against the original, probably fixing some awkward conflicts from previous commits to your clone if you haven’t used branches for everything as I suggest below. It looks like people often create new clones for each merge request.

Create a branch in your remote clone

For instance:

• git branch mr_dosomethingtofooforgoo master
• git checkout mr_dosomethingtofooforgoo
• Make your changes, add and commit them.
• git push origin mr_dosomethingtofooforgoo

Request a Merge

Click the “Request Merge” button at the right, when looking at your clone’s top-level. For instance. There is no “Merge Request” button when looking at an individual commit, or even when looking at a branch. This would make it far easier to submit small changes.

Then you must copy/paste the first-line and details from your commit message into the two text fields on the Request Merge form.

You must also choose your branch name from a drop-down list and choose the commit from that branch that you want to use.

Then you can finally click “Create Merge Request”.

Yay! Almost one month since the last time I wrote. I need to improve this :). There is a convincing excuse though. Since I started my job at Openismus, another evening full-time job came out: the search of my new apartment!. It seemed to be an easy task at the beginning, but now it just turned into a complicated competition. I have just realized that writing in your presentation e-mail that you have something to do with informatics may probably be not that popular. Being non-smoker seems to be another problem too.

At last, things at work could not be better. During the first week we dedicated our time to install Fedora 13 in our computers. Apart from some issues with our keyboards concerning to the language layouts, everything went fine. We learnt to know as well, how the "internal communication system" here works and joined some lists to be up to date with all project's news. Then we started with jhbuild!. That was definitive lots of fun: is there anybody that run it without having to fix at last 2000 errors? ;). Thanks God or whoever, Chris, David and Saint Google were there for support. We actually learnt a lot.

The second week started really good since we finished fixing the jhbuild's errors, and moved on to GTK+. I was busy with this till Thursday. On Friday and Saturday we went to the Linux Tag here in Berlin and attended a series of interesting talks about MeeGo, systemd, Google, Ubuntu and Gnome 3.0. The talks were interesting, but more business-orientated in general from my point of view. However, the best part of this kind of events are the "after-talk-times", where you get to know some people involved on different open source projects or people that work / worked in the same company you do and still did not know. Better chances of socialization came in the evenings with the barbecues at C-Base!.

Well, now it is time I stop writing here and go on learning some GTK+, since I have to present some legible code today.

See you soon!

(I’m not the first person to cover this topic, anyway.)

After upgrading my Nokia N900 to the latest software version (PR1.2) I got a “MyNokia” screen after rebooting.
Nokia was kind enough to offer me both subscribing to their MyNokia service by sending Nokia an SMS message and to read the Terms and Conditions of their service (Terms and Conditions that some people consider either incorrect or even illegal).
I assume that in the hurry of getting the PR1.2 release out in time Nokia probably simply forgot to add a “Do not subscribe me” option. But who needs that anyway? It’s hard to imagine why people would not want to use it. You just give Nokia some of your private data and in return you get some cool and totally useful tricks and tips for your N900 that… you had known before already? Nah, come on!

Sending SMS to Nokia costs money as per Terms and Conditions (“Use of the Service may involve transmission of data through your service provider’s network. Your network service provider may charge for such data transmission.”) Also it’s not clear if the message will be sent to an international number or not (different costs).

So I removed the battery to switch off the device. But booting brought up the dialog again. So the available options are “Subscribe” and “Do not use your device”. By subscribing I send them data such as… hmm, what exactly? I cannot find a clear list in the Terms and Conditions. Does Nokia care about my privacy?

After successfully subscribing you receive an SMS welcoming message from Nokia which does not tell you from which exact phone number but there are users that extracted a list.

To unsubscribe I had to send an SMS again to Nokia that I pay for again. So I went to the Settings section and tried to unsubscribe. And failed with a generic error: “Nokia: Attempt to unsubscribe has failed. Go to ‘My Nokia” in Settings to try again. Visit www.nokia.com/mynokia for more information.”
The second sentence told me to try again. So I tried again. And paid again. And failed again. And realized that the UI does not give any indication whether you are currently subscribed or not.
The frustrating user interface could be easily fixed by anybody if the code was open source.
It is not.

Dave pointed out that there is a workaround for this registration. And there are dozens of complaints, also from other series than Maemo, which makes me wonder if Nokia Marketing is actually aware of this.

It was easy to get an answer to my previous question “Does Nokia care about my privacy?”: I simply went to Nokia’s website which states “WE CARE ABOUT YOUR PRIVACY” at the top.
Unfortunately they only offer me a postal address in Finland to find out what that exactly means as I have some open questions left – for example which exact data is stored. In accordance to German law I must be told (§ 6 Abs. 2, § 28 Abs. 4, § 34 Abs. 1-3 BDSG, § 34 Abs. 1, § 43 Abs. 3 BDSG).

As written in the Terms and Conditions, “Except as set forth in Privacy Policy, Nokia shall not be responsible for any removal of the information or content you have submitted (“Material”) from the Service when your registration is terminated.”
IANAL, but that does not sound legal to me.

So if a Nokia Legal person can explain to me how their service and its terms are in accordance to German law (esp. §4 Abs. 3 BDSG) feel encouraged to leave a comment on this blog or send me an email. If this will not happen there are ways to force you to, as already listed here.

PS: Those who find irony in this posting are free to keep it.

• Openismus day 9: Went to Linux Tag here in Berlin. Attended talks about MeeGo, systemd and Google & open source. After-party at c-base. #
• Openismus day 8: more gtk+, tracking down bug in glade3. Decided to learn Emacs on my own time. Got Eclipse set up with Linux Tools plugin. #
• Openismus day 7: Did more gtk+ and emacs. RSI getting worse, though. Think I'm going to start wearing my wrist brace and see a doctor soon. #
• Openismus day 6: more gtk+; looked into glib, gobject, and coding conventions for gtk+/gnome. more emacs setup. #
• Openismus day 5: finished this round of jhbuild, started setting up emacs, started looking at gtk+ more. #

(copying from devel-announce-list)

The GNOME Release Team plans to ship GTK+ 2.90 from GNOME 2.31.4 on.

This requires module maintainers to port their modules now (if you don’t want an angry release-team mob soon in front of your house).

We strongly encourage maintainers to

• fix compiling with GSeal (see if your module is affected)
• remove/replace calls to deprecated GTK+ symbols (see if your module is affected)
• fix GTK+ modules (see if your module is affected).

The following modules are affected (list not necessarily complete):

	GSeal	Deprec. symbols	GTK+ modules
bug-buddy			to do
ekiga	to do
empathy	to do
epiphany	to do	to do
evolution	to do
gdl	to do	to do
gdm	to do	to do
glade3	to do
gnome-disk-utility	to do
gnome-netstatus	to do
gnome-panel	to do	to do
gnome-screensaver	to do
gnome-terminal	to do
gnome-utils	to do
gtk-engines	to do	to do	to do
gtk-vnc	to do
libcanberra			to do
libnotify	to do (fixed in git but needs new tarball)
librsvg			to do
libslab	to do
libwnck	to do
metacity	to do	to do
nautilus	to do
raptor		to do
seahorse	to do
seahorse-plugins	to do
sound-juicer	to do
swfdec	to do
system-monitor	to do
vala	to do
vinagre	to do
vino	to do
vte	to do
webkit-gtk	to do	to do

For a longer list of issues remaining for GNOME 3, take a look at Bugzilla.

That was easier than I expected. After a bit of googling and hand-crafting libtool archives, Rygel’s plugins now work on Windows as well. Now I just need to clean-up all that hackery.

• Openismus day 4: more jhbuild (Is there anyone for whom this works?), read up on gmmproc, made my first patch with amigadave's help. #
• Openismus day 3: opened bank account, more jhbuild, mailing lists, autotools tutorial, read a few "items" in "Effective C++." #
• Openismus day 2: started building GNOME with jhbuild, went to doctor w/ Anni for ultrasound, more jhbuild, read mailing lists and c++ book. #
• Finished first day at Openismus. Met some co-workers, set up computer, installed dev packages, configured accounts and ate falafel. #

*mm documentation on library.gnome.org

We’ve finally moved the API documentation for gtkmm and the other C++ bindings to library.gnome.org’s C++ Reference section. These are all created with Doxygen. Using library.gnome.org means that it’s updated every time we do a tarball release and we don’t lose old versions when it’s updated. We also have both the stable (on distros) and unstable (in progress) API documentation available.

We’ve also moved the gtkmm book, libsigc++ manual, and libxml++ tutorial to the Guides section. These all use DocBook XML.

library.gnome.org is a wonderful system, giving developers what they need, thanks to Frederic Peters’ hard work and responsiveness. I like it so much that Openismus might soon offer to set up library instances for other projects or companies.

Main Pages

Moving the API documentation to library.gnome.org made it obvious that we needed proper introductory text for each module. So each one now lists:

• What it is
• Where in the API to start looking, with links
• How to #include the headers
• How to get the include and linker flags with pkg-config

For instance, see the glibmm API reference’s main page.  I regularly complain that non-GNOME libraries don’t provide clues about what include or linker flags should be used, or how to include them, let alone API documentation, causing application builds to be inconsistent and fragile. It’s the least that should be done, so it’s good that I can now point to something consistent.

Lingering Problems

There are some small problems still to work out:

• gtkmm’s stable/ page shows the unstable 2.90 releases
• libxml++’s main page isn’t showing in library.gnome.org
• libvtemm’s main page isn’t showing in library.gnome.org
• gtksourceviewmm (and probably others) needs library.gnome.org’s server to have Python 2.6
• gtkglextmm doesn’t have a main page yet