Posts tagged ‘gnome’

Jendela to save Metacity

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/.

Abandoning OpenBox for MetaCity

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 :-)

Epilicious in BZR probably broken…

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 :-)

Epiphany rocks!

Read a post on epiphany-user yesterday on how a hidden location bar appears when Ctrl-L is pressed. Then it goes away again. Very nice. It also seems that the version in Debian keeps information about “Generic Postscript” printing–I don’t need to enter a2ps in the text box anymore, it’s remembered.

I just love how the irritation points in the GNOME UI just keep on disappearing :-)

Epilicious ready to be localised

The current version in BZR, that’d be version 0.8pre1, has internationalisation support. Currently there’s only one language, Swedish, but I’m looking forward to receiving onther languages to add to the list. (I’m more than happy to receive any pointers regarding the language in epilicious, be it English, Swedish, or any other language.)

The actual implementation was very straight forward, basically I copied what’s in Python’s gettext documentation. I read some other documents as well, just to know what I was getting myself into :) The GNOME developers have two documents worth reading. The first one, internationalising GNOME applications, contains what you need to know about internationalising the different types of source files in a GNOME application. The second contains localisation guidelines for developers, it’s not as technical as the first but it’s a good complement to the first.