therning.org/ magnus

The other day I had some problems early on when trying to compile from GNOME CVS using jhbuild. From a sudden surge in brain activity I got the idea to build a release of the development version of GNOME—the 1.15.x series—the lates one is 2.15.4.

I got some help from Elijah Newren’s post on compiling GNOME with jhbuild. Using the links from the release notice on FootNotes I got as far as

% jhbuild bootstrap

without problems. Then I got stuck:

% jhbuild -m \
> http://ftp.gnome.org/pub/GNOME/teams/releng/2.15.4/gnome-2.15.4.modules  \
> build
jhbuild build: dependent module "libdaemon" not found
usage: jhbuild [ -f config ] command [ options ... ]

My first thought was that installing the Debian package libdaemon0 might solve it. Of course it didn’t. Then I remembered that during bootstrap Python 2.4.3 was downloaded and installed, despite being installed on my system already. Not too much of a surprise then that libdaemon0 didn’t do any good.

After looking at jhbuild modulesets for previous releases as well as the bleeding CVS moduleset I got an idea. I saved the 2.15.4 moduleset locally and modified freedesktop-2.15.4.modules to include the following lines:

<tarball id="libdaemon" version="0.10">
  <source href="http://0pointer.de/lennart/projects/libdaemon/libdaemon-0.10.tar.gz" />
  <branch checkoutdir="libdaemon" module="trunk" repo="libdaemon.0pointer.de"/>
</tarball>

It’s compiling rather happily at the moment so I’m optimistic… I’ll add a note if things go pear-shaped…

I’ve just released version 0.9 of epilicious. A package for Debian has of course also been uploaded to my personal APT repo. Have fun!

Oh yeah! Almost forgot. Translate it, please!

Since it’s been some time since the 0.8 release of epilicious and I’ve been doing some work on it lately I thought it’s time for a release soon. I should be able to get around to it in a day or two.

I went over the translations and realised that they’re all going to be out of date when I make the release. Reading through the document on L10N Guidelines for Developers I considered sending a POT file to the Translation Project. I didn’t send an email for two reasons:

1. Epilicious contains 18 translatable strings. It just feels like it doesn’t belong with apps like xchat.
2. I’m still hoping I’ll be able to get it into GNOME CVS at some point as an official plugin for epiphany. Then the GNOME Translation Team would get involved but unfortunately they won’t touch it until it’s in GNOME CVS.

For now I’ve uploaded the POT file. Please, please, send me a translation!

I just noticed that epilicious doesn’t work for me It seems the recent work done by the Python group in Debian Sid has resulted in the following line throwing an exception:

from elementtree.ElementTree import parse

Yes, I’ve double checked that python-elementtree is installed (python-celementtree is also installed). At the moment I’m too lazy to look into it myself and I’ve sent off an email to the Debian user list.

I’ve just checked in a small fix for a rather irritating bug in epilicious. I’m surprised no-one noticed the bug earlier. A local modification to the keywords of a bookmark wasn’t propagated to del.icio.us, and a second sync would revert the local change.

I’ve checked in a fix and built a new package of course.

Just uploaded a release, version 0.5, to GnomeFiles. Of course I also created a page for it.

Hopefully someone will enjoy it.

After an attempt at hacking “window packing” into Jendela I ran into a bit of a showstopper: Metacity doesn’t support _NET_MOVERESIZE_WINDOW. Now this is a bit of a problem, because “window packing” is all about moving windows around on the screen.

Confusingly Metacity does register the relevant XAtom, meaning that wmctrl doesn’t work (it’ll first try the XAtom, if it exists it uses the EWMH way, otherwise it reverts back to calling XMoveResizeWindow). Bad, bad Metacity!

Well, it turns out the code is already in Metacity, just commented out. The changelog says it’s pending “feature thaw”, whatever that means. Apparently something’s frozen solid because it’s been pending since July 2004

I decided I need to take a stab at this and raised bug 344521.

My local development repo is being uploaded to http://therning.org/magnus_bzr/jendela.dev/ as I write this.

There isn’t much functionality yet–you can shade windows–but hopefully I’ll have time to change that over the next few days.

Unfortunately it seems the Python bindings for wnck aren’t quite up to scratch. I’m getting numerous run-time warnings and sometimes even segmentation faults when doing some stuff (e.g. when shading all windows on the current desktop). I’ve “verified” it’s a problem in the Python binings by hacking together a quick and dirty program in C that does the same thing, with the difference that it doesn’t segfault

It turns out this was just the excuse I needed to take a closer look at the GLib object system and GObject. It was a long time since I wrote anything real in C (experimentation on Windows just doesn’t count) and I’m enjoying myself.

For now the Jendela-in-Python BZR repo is taken down, soon to be replaced by a repo with Jendela-in-C.

Well, the last few days I’ve been filing bugs and trying to write patches. They are all related to my intention of getting rid of Openbox and using Metacity in its place. This is the current list:

• Bug 342899 adds a function to libwnck to set a window’s geometry. Done and approved
• Bug 343332 fixes a bug in the Python bindings for libwnck. With it in place it’s possible to get the geometry of a window. Done, but not approved.
• Bug 342900 is related to 342899, it adds Python bindings to the function in that bug. Still in progress, having some problems with the enum/flags that currently prevents me from testing my patch.

I guess this makes it pretty clear what I’m intending to do. I call it Jendela. It’ll be a command-line tool for window manipulation, written in Python. Ideally this tool will make it possible for me to implement the window manipulation functions that I think are missing in Metacity (see below for an explanation why I think this is a good thing). Combine it with something like xhotkeys or xbindkeys and Metacity will become a lot more usable indeed.

So, why do I think Metacity missing features is a good thing? Well, it’s simple, it’s the Unix way! Metacity should be kept lean and mean, small in size and number of features, but good at what it does. Then there should be ways of connecting other programs to influence Metacity’s behaviour. That is where libwnck comes into the picture. I’m hoping that one day Metacity will start removing features relating to keyboard shortcuts for window manipulations due to tools like Jendela. Well, that’ll probably remain a dream for a long time to come though.

Jendela is not ready for consumption yet but I’m trying to push my bzr repo as regularly as possible. You can find it at http://therning.org/magnus_bzr/jendela.dev/.