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:
- Epilicious contains 18 translatable strings. It just feels like it doesn’t belong with apps like xchat.
- 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/.
For a long time I used Sawfish as my WM. It wasn’t the official GNOME WM, and it did falter in its GNOME compatibility in places. On the whole though it was a good WM, and most importantly, it was programmable. Comparing a tool that’s configurable to a tool that’s programmable is like comparing a KinderEgg toy to a box of Lego. I programmed Sawifish to let me control windows extensively using no mouse.
Then Sawfish stopped being actively maintained.
Rather than holding on to a piece of software that was falling more and more out of date I made a switch to OpenBox(OB). OB is configurable. This meant that some of the things I was used to do with Sawfish wasn’t achievable in OB, at least not without some serious hacking on the code. However, there are a few things that irritate me with OB. Nautilus, in its spatial view, will only open a single window for a specific location. When a location is opened a second time the already opened window is “re-used”. In OB this results in a switch of workspace, i.e. I’m spirited away to whatever workspace the window is on at the moment, leaving behind all the windows for the task I’m currently occupied with. Less than ideal I’d say. The ideal would be if the Nautilus window was moved to the current workspace instead. Then of course I miss some of the functionailty I programmed myself in Sawfish, OB just doesn’t offer the same level of control over windows as I had programmed into Sawfish.
I’ve decided my OB days are over, time for MetaCity.
I’ve always shunned away from MetaCity. It’s even less configurable than OB and there is no way I’ll be comfortable using it for my WM. I can’t live without the keyboard control of windows! So, why switch? I’m hoping that’ll be obvious once I’ve posted the next blog entry
A recent email from a user pushed me to go see if there’s a newer version of the Python del.icio.us API I’m using for epilicous. I found version 0.3.2 and the author, Frank Timmermann, has found a new space to host it. There’s been some renaming it seems, it’s now called pydelicious. Here’s the link for pydelicious.
Anyway, this version has a slightly changed API and I still haven’t gotten around to checking whether epilicious in BZR is functional or not. You have been warned