Steve Frécinaux

Mathusalem gets useful

Yesterday night, I released the third 0.0 version of Mathusalem. The visible part of the iceberg includes a new UI, which is way cleaner than before. But it also features a client (synchronous) library and, last but not least, a small rough patch allowing Epiphany to use Mathusalem!

The new UI

So the old ugly window has been dropped. Now, Mathusalem looks more like any regular applet popup. I was in the idea to make it look more like a menu but I finally prefered to go this way:

Screenshot: New UI The new Mathusalem UI

As you can see, the UI is divided into two parts: the task list and a toolbar (located at the bottom). The task list shows the current progress, the task state (is it running, paused, aborted?), its name and the owner. The toolbar allows you to actually control the currently selected task: if the corresponding action has been registered for that task, you’ll be able to pause, resume and cancel it using the relevant button at the bottom of the popup. The button at the bottom right is only useful to close the window, clicking on it has the same effect than clicking on the notification area icon once again.

As I said, these bottom buttons are sensitive only if the corresponding action has been registered for that task. This can be done by using the AddAction method on it. The relevant action names are ⤽start⤝, ⤽pause⤝ and ⤽stop⤝. When one of these is hit, a ActionTriggered signal is sent, so that the task owner can react the way it should.

A client-side library

Now there is also a client-side library shipped with Mathusalem. This library uses mostly the same API than the server (actually, the interface-related code is just shared between both of them), and this chunk of code is sufficient to register a new task:

MalemFactory *factory;
MalemTask *task;
static const gchar *interfaces[] = {

factory = malem_factory_client_get_default ();
task = malem_factory_register_task (factory,

And that’s all!

Anyway this library has a severe drawback: it’s synchronous. Well, not fully, because only very few functions need to access the bus. For the other ones, either they don’t return anything (so there is obviously no need to wait for the return values), or they can just return the value of an internal variable of the proxy object, a cache being kept and updated using signals.

This approach was prefered because it’s way simpler and is usable without further thinking. But it blocks the UI. In the long term an async API would of course be required and prefered to the current one, but well, we’re still in 0.0 proof-of-concept state. It’s not that bad actually (due to the cache) and it’s still possible to use the D-Bus API directly anyway, isn’t it? ;-)

For the sake of Epiphany!

Last but not least, there is now a patch to make it possible for your beloved browser to use Mathusalem as a download manager. Look at the above screenshot: if the Synaptic-related task is still a dream, the other one is… real, yeah. To make it work, just install Mathusalem, and patch your Epiphany version with the above-mentionned patch.

Hint: you can run epiphany -p from the compilation directory to avoid any interaction with your installed version.

Where to gather it?

The release tarball can be found here (md5sum: 37513ba7005e3676205cf464db7e74da). If you prefer bleeding edge, the git repository still lives at the same location than ever:

You will also need this D-Bus patch (md5sum: 179654f4cfc7415ddb508c5429bd32e0). It hasn’t changed since last time.

And you can also try the proof-of-concept patch for Epiphany (md5sum: 4503092bbbc8921952b9aa2085c31d77).

Update: I messed something in the make install, so if you want to use the library you’ll have to copy manually the missing files into /usr/local/include. These files are malem-frobnicator.h and malem-enum- types and are located in src/interfaces in the tarball source tree.