cluttermm 1.18

cluttermm provides gtkmm-like C++ bindings for the Clutter API. It hasn’t had much attention over the last few years, while the Clutter API has moved on considerably.

I don’t have a great interest in Clutter, though I’d like cluttermm to be ready to inspire gtkmm if any future GTK+ 4 absorbs Clutter. However, Ian Martin has recently put lots of work into updating cluttermm and I’ve been helping him to get his changes upstream and I released some cluttermm-1.17.x tarballs. It’s in the cluttermm-1-18 branch.

This has involved deprecating a huge amount of API and adding (hopefully all of) the API that replaces it. I’ve already removed all this API in the parallel-installable cluttermm git master branch but I have some linker errors that stop that from building, and I’m not going to spend time on it until there are some releases from clutter’s git master (clutter-2.0).

This also means that the cluttermm-tutorial is even more wildly out of date. I’m not likely to spend my free time updating it.

I don’t want to be cluttermm maintainer again, but I didn’t want Ian’s work to be wasted and I hope he wants to keep at it.


glibmm 2.40 and gtkmm 3.12

Only a little late, we released stable glibmm 2.40.0 and gtkmm 3.12.0 versions.

This was only possible thanks to lots of work from Kjell Ahlstedt and  Juan Rafael García Blanco. For instance, Juan added the Gtk:::ActionBar, Gtk::FlowBox and Gtk::Popover classes,after having added Gtk::HeaderBar, Gtk::PlacesSidebar, Gtk::Revealer and Gtk::SearchBar in gtkmm 3.10. They also added example code in gtkmm-documentation.

Openismus Over

Last week I was at a notary here in Munich to officially put Openismus GmbH into its liquidation phase, after seven years. The company is closing down, though with no debts and with a little left over. I feel good about that.

This has been the plan for a while since it became harder to get reliable customer work, though that was more a result of the company structure and my own time constraints than any particular change in the tech economy. It became possible once the last few employees had found good jobs to move on to.

I got past any sadness about this a long time ago. I guess it would be nice for things to be running along at their best again, but there was never a sense of security and always a stressful balance of risk and responsibility. It was a good problem to have.

For the last year or so I’ve mostly been busy with all the tedious work of shutting down the offices in Munich and Berlin along with the day to day paperwork involved in a company. Now I feel a sense of relief to be free of these responsibilities.

It will be a few months until I start to look seriously for what’s next. I’ll probably look for a nice stable development and management job here in Munich, and I’ll try particularly hard to find something that lets me work part time so I can pick my kids up from school.

In the meantime I’m enjoying the small sense of achievement that comes from taking care of all the little things I’ve let slip over the past few years and catching up with a bunch of tech stuff that I haven’t had time to learn in depth.

Lego Wedo with MIT’s Scratch: Simple Robotics for Kids

Lego Wedo

Last week my son, who has just turned 6, tried out the Lego Wedo kit that I’ve had sitting in the cupboard until I thought he was ready. It’s a very simple system of sensors and a motor that plug into a computer via a USB hub so the child can write simple programs to control it. For instance, the program can turn the motor on or off depending on the whether a sensor detects something.

It’s a nice simple first step into programming and robotics for kids that aren’t old enough to deal with Lego Mindstorms, which I guess needs a higher level of reading and writing skills. Controlling real objects in the real world is interesting enough to small children. As robotics is not yet pervasive in everyday life, the limited functionality is helpfully simple without seeming unimpressive.

It’s the best equivalent I’ve found for my own first programming experiences with BASIC on the Sinclair ZX81 when I was 8 years old. That didn’t allow anything but programming from the moment you turned it on, and the BASIC keywords were just a keyboard press away. Putting text on the screen and reading text input was new enough to keep my interest. Today, children expect computers to do much more impressive things on a screen. But they don’t expect so much from Lego.

I talked my son through building the programs, encouraging him to start with simple steps, checking that they worked, finding out why they didn’t work, and then building upon that step, until he had a whole program. For instance, first we would make something move, then make it move as we wanted, and only then think about how to make it move only at certain times or how to make things happen onscreen. Plenty went wrong so he had a chance to learn that errors and debugging are normal.

Lego Wedo is part of the Lego Education line, which is aimed at schools, and their procurement processes, rather than general consumers. This need to support a network of distributors, and to provide curriculum support and lesson plans, is probably why it’s so expensive. The Basic Lego Wedo set (Lego kit 9580) is 129.95 Dollars in the US, or 148.74 EUR in Germany. Until recently, it was hard to buy this stuff as an individual, at least here in Germany, but the Lego Education online shops (listed here) now allow this. And the Lego Wedo kit is available on from third parties. It’s probably worth looking on ebay too.

Scratch instead of the Lego Wedo Software

The kit is useless without software, so you usually need to buy the Lego Wedo software separately, making the whole thing even more expensive (89.95 USD in the US, or 101.14 EUR in Germany, though I think it used to be twice as much). It runs only on Windows and Mac.

Luckily, MIT’s Scratch 1.4 has support for Lego Wedo. It “just works” on Linux, at least on Ubuntu Linux and Fedora Linux. Scratch is available for Windows and Mac, so I guess that it will work there too.

We have an OLPC XO laptop which has Scratch installed by default, which works perfectly with the Lego Wedo. I recommend this setup wholeheartedly because then the child doesn’t need to deal with all the surrounding crap in an adult’s operating system and doesn’t need permission or help to start playing. Unfortunately, I don’t know how individuals can buy these now, though you might have luck on ebay.

I’m not a fan of Scratch’s user interface because it expects kids to drag and drop, or click, on tiny targets and read tiny text. I guess that the official software is much easier. But Scratch is way better than nothing, and my 6-year old child can handle it now.

When the Lego Wedo USB Hub is connected, the Motion and Sensing areas have extra Lego Wedo Scratch blocks for use with the motors and sensors.

Unfortunately, the latest version (2.0) of Scratch, as seen on the main Scratch site, is browser-based, using Flash, though they are apparently aiming to rewrite Scratch in Javascript. It doesn’t seem likely that the online version will support hardware such as Lego Wedo any time soon, though it’s apparently in progress. Luckily the older versions are still available and still work.

Lego Wedo Hardware

The Lego Wedo basic kit has one motor, a distance sensor and a tilt sensor, along with the lego pieces, such as blocks, cogs, and axles, needed to build the models seen below. That’s obviously fairly limiting, but it’s enough for some first steps for young children.

The official Lego software can apparently control multiple motors, and multiple USB hubs, but MIT’s Scratch can only control one motor without installing a custom thingy.

The Lego Wedo motor is the same as the Power Function motors that can be bought separately  or that come with big Lego kits such as the Lego Technic 4×4 Crawler which my son has just built. However, these motors and sensors are not compatible with the Lego Mindstorms system (neither the older NXT nor the newer EV3 systems), which is rather annoying.

Lego Wedo Models

We built a few of the basic Lego Wedo models using the online PDF instructions. The advanced models, such as the ferris wheel, need (unusual) parts from the LEGO Education WeDo Resource Set (Or “Expansion Set” – Lego kit 9585) but we might try building something similar with what we have.

We had to think up suitable Scratch programs for ourselves, but that’s a useful exercise. The Lego Wedo Teachers guide (see Activities here) has some helpful suggestions about what you might try to achieve.

We built these models:
(View this at the original page if you can’t see the (done in a rush) embedded videos.)

Hungry Alligator

The alligator snaps its jaws open and shut when your finger gets close enough. Our program kept checking the distance sensor, and when that had a small enough value, we turned the motor on in one direction for some time and then in the other direction for some time. We had to make sure that the mouth was open when it finished, or it would block its own sensor and keep snapping forever.

Here’s a picture of our program:

Goal Keeper

The goal keeper moves around in front of the goal. The distance sensor behind the goal detects balls moving past it, so the program can keep score. We had two sets of blocks – one to move the goal keeper at random, and one to keep checking the sensor, incrementing a variable and showing its value on screen. We hacked in a wait to stop it from incrementing the variable too much as the ball passed the sensor but this could be cleverer.

Here’s a picture of our program:

Flying Bird

The bird’s body and wings can be moved manually. There’s no motor in this model. It’s just a fancy way to trigger the distance and tilt sensors. When the body moves, the tilt sensor triggers a flapping sound from the computer, and when the head blocks the distance sensor, the computer makes a chirping sound. Scratch has a bird chirp sound by default but we had to record ourselves saying “flap” for the other sound.

The tilt sensor is rather imprecise, and only provides one value at a time to indicate one of flat, up, down, left or right, which doesn’t make much sense. Scratch displays the value as a number between 0 and 4 which makes things hard for kids. The meaning of each tilt value is mentioned here.

Drumming Monkey

The monkey’s arms move up and down due to the motion of the rotating cams attached to the motor, letting you change the rhythm by changing the motors speed and duration, and by changing the positions of the cams and the arms. This model has no sensors. It’s rather underwhelming.

Here’s a picture of our program:

jhbuild and clang’s scan-build

I love C and C++ compiler warnings, particularly when I can fix the problems they show. I love getting new warnings for code I thought was clean. There are always a few warnings that show serious mistakes.

I recently noticed that, since 2011, jhbuild can do some extra static code analysis, using clang’s scan-build tool. This is thanks to Jeremy Huddleston and friends.

It’s pretty simple, though I don’t think it’s in the jhbuild manual yet. It should work if you just install scan-build (from your distro package, such as the clang-analyzer package on Fedora), and add this line to your .config/jhbuildrc file in your home directory:

static_analyzer = True

My scan-build here on Fedora 19 didn’t seem to find its own clang executable, so I had to add this line too:

static_analyzer_template = 'scan-build --use-analyzer=/usr/bin/clang -v -o %(outputdir)s/%(module)s'

I wonder if any systems are running this regularly. I’d like to just view it online every now and then. My local /tmp/jhbuild_static_analyzer/ directory is full of lovely scan-build reports for various GNOME modules but I’m sure others would enjoy that bounty.


glibmm 2.38 and gtkmm 3.10

I just released glibmm 2.38.0 and gtkmm 3.10.0 – stable releases of API that we’ve been working on for a while.

This adds several new widgets that were added in GTK+: HeaderBar, ListBox, PlacesSidebar, SearchBar, and Stack. Thanks to Juan Rafael García Blanco, Andrew Potter, and Kjell Ahlstedt for that hard work.

It deprecates StockID, Table, IconFactory, IconSet, IconSource, and Gdk::Color along with several methods.

This glibmm release also has a fairly useable API for Gio::Menu and Gio::Action so you can really create gtkmm Menus with them and Gtk::Builder (here is an example). But unlike GTK+, we decided not to deprecate Gtk::UIManager, Gtk::Action and friends yet.

Most importantly, and most difficult to notice, we have deprecated deriving from Glib::Object before deriving from interface classes (such as Gtk::TreeModel). So you need to make changes such as this. The previous use of interface classes as the last base classes, after Glib::Object (which used to be the only way to use them) will cause runtime warnings in glib for now, and will probably break your application’s functionality in future glib versions. It’s not what we want.

Openismus Mini

As I mentioned last year, Openismus managed to stabilize for a while after we first had to slim down from 16 employees at our height. Our core team took on greater responsibility and worked hard to transform the company, with incredible results.

However, we haven’t managed to sustain that, so we’ve recently had to lose more great developers and close the Berlin office, keeping just the Munich office. There are many ways to look at it but in the end we must yield to the mathematics. Luckily, we’ve managed to help some people move over to KDAB in Berlin, who we’ve been working with recently. KDAB are good people who do similar work, mostly around Qt, though they are larger and sustainably successful. I’m sure that our ex-Openismus stars will drive a trail of success wherever they choose to go, still fighting entropy. I’m not too sad now that I know everyone is OK and because I know that we’ve had time to try things.

Openismus will continue at least for now, working on Rygel and Evolution-Data-Server as we still have a little customer work there. But we can no longer employ sales people, so we’ll have to hope that little contracts turn up here and there through personal contacts. I’m not optimistic, mostly because the last few months have worn down my perseverance.

We no longer have the capacity to work on the Maliit on-screen keyboard. However, the project is still very much alive and I believe that Develer and KDAB can offer quality Maliit consulting. We just couldn’t wait around long enough for the right customer to sign a contract.

Likewise, we have lost our Wayland expertise, but Jan Arne Petersen, who did the Wayland Input Methods work, will be working at KDAB, so I’m sure that an interested customer could continue to fund similar work.

C++ in Glom: shared_ptr and slots/functions

I’m playing more with C++11 in g++ (Use –std=c++11), this time with Glom.


Glom has a custom reference-counted shared pointer, Glom::sharedptr, which seems to work well, but I was glad to replace it with std::shared_ptr so I never have to wonder if it’s working properly. Krzesimir showed that I could make it a little more concise by using std::make_shared(). I’ll use auto some time to make it even neater. For instance, make_shared() takes the parameters to the constructor of the class:

auto some_thing = std::make_shared<SomeThing>(1, 2, 3);

It’s a lot like glibmm’s Glib::RefPtr, though that lets GObject do the reference-counting, so one day glibmm/gtkmm will have similar changes.


glibmm still uses sigc::slot with sigc::signal, but I had some application code that used its own slots as callbacks. So I changed these from sigc::slot to std::function. The new syntax doesn’t feel quite as nice. For instance:

Replacing sigc::slot declarations with std::function

std::function uses a slightly different syntax than sigc::slot for declaring its functors:

sigc::slot<void, int, int> some_slot;

would now be this, which I guess is OK:

std::function<void(int, int)> some_slot;

Using non-member functions

sigc::ptr_fun() has no equivalent, so this:

std::slot<void> some_slot = std:ptr_fun(&some_non_member_func);


std::function<void()> some_slot = &some_non_member_func;

though that same syntax is legal with libsigc++ too. The & is optional when getting function pointers in C or C++, but I like it.

Using member functions

sigc::mem_fun() has no equivalent either. std::mem_fn() just gives you the member function without associating an instance, so you need to use std::bind() to get both. So, this:

std::slot<void> some_slot = sigc::mem_fun(*this, &SomeThing::some_method);


std::function<void()> some_slot = std::bind(&SomeThing::some_method, this);

That becomes particularly awkward if your member method takes any parameters, because std::bind() expects you to supply all parameter values when using std::bind(), not just when calling the slot/function later. std::placeholders::_* is the awkward way to work around this (thanks again to Krzesimir). So:

std::slot<void, int, int> some_slot = sigc::mem_fun(*this, &SomeThing::some_method);


std::function<void(int, int)> some_slot = std::bind(&SomeThing::some_method, this, std::placeholders::_1, std::placeholders::_2);

Presumably this simplifies the implementation, but the result is that the common case is less readable. Still, I’d be glad to have one less library (libsigc++) to think about if we can ever replace sigc::slot with std::function in glibmm and gtkmm. However, C++11 does not yet have any equivalent for sigc::signal so we’ll still need libsigc++ for a while.

C++11 in glibmm

I haven’t had much chance to play with C++11, though I’m supposed to be a C++ expert. It’s just hard to use it in a project when not every platform has the compiler support. However, with gcc making such progress on C++11 support, it feels like my projects (glibmm, gtkmm, glom) could switch to C++ only some time soon.

So I’m playing with some of the most obvious new features in the glibmm example code, in a branch. Here are some little commits to demonstrate:

gtkmm 3.8

I didn’t get around to blogging about gtkmm 3.8 when I released it last month, partly because we had to fix a crasher bug and do a gtkmm .1 release before people noticed.

Anyway, just a little while after GNOME 3.8 was released, we managed to release gtkmm 3.8 and glibmm 2.36. There is quite a bit of work in these, almost all by José Alburquerque and Kjell Ahlstedt, as well as the usual few days of last-minute work by me to wrap remaining new API.

I spend very little time on glibmm and gtkmm these days, and don’t have much motivation to change that.

There’s also a change that we expect in glib 2.38 that will break many installed applications that use gtkmm. We successfully begged the glib developers to add a special case for us in glib 2.36, but we have not found any way to avoid this for 2.38. So far our best option seems to be to do a new parallel-installed gtkmm (and glibmm) ABI, leaving the old (broken with glib 2.38) one behind, at least allowing applications to be changed slightly and then rebuilt.

Personally, I have no great incentive to go through that pain.