Archive for May 2006

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

Slashdot Coincidences

I don’t really have time to follow slashdot every day, but since most of the interesting goings on are posted there sooner or later I’m subscribing to the daily email of slashdot headlines. The drawback is that I get the news a day late, but on the upside I get to see what I’d call Slashdot Coincidences.

May 19 saw these two stories posted on Slashdot:

BZR 0.8 for my development

Epilicious Frappr Map?

I know, I’m pathetic but after doing some brainless web surfing on frappr I couldn’t help but have the thought. Now, it’d be utterly pathetic if I’m the only one on that map. I leave it up to you. Yes, I mean you! Send me a comment to this telling me that you’ll sign up on the Epilicious Frappr Map and I’ll go ahead and create it :) (I’m guessing two people on a map is about half as pathetic as a single person.)

aptitude doesn’t suck, actually

I have to say I was a little worried when I saw the installation notice during a recent upgrade of debfoster. It had been deprecated, abandoned by its developers, and instead I was being encouraged to use aptitude. So, I was being forced to give up my favourite package tool for a tool that I’ve started a few times but always found too confusing to invest time in learning.

My first step was the transition from debfoster to aptitude. I tried out the debfoster2aptitude script that was added to the last upgrade of debfoster but quickly realised that it was asking questions on a level that was way too low. I decided to do it manually instead. First I minimised my list of packages in debfoster and saved a copy of it:

# debfoster
# debfoster -qmn
# debfoster -a > ~/debfoster_keepers

Then I turned to aptitude. First I marked all packages as automatically installed (auto) from the command line:

# aptitude markauto '~i'

Then I marked each of the packages in /root/debfoster_keepers as not auto. I did this using the UI, which was both boring and time consuming. It should be easy to wip up a shell script for it, but I felt I needed to get used to aptitude’s UI a bit. After this I went on to see what the damage would be–I hit ‘g’ to add/remove packages. As expected there were a few packages in there that I had to tell aptitude to keep installed for me. No big deal.

One interesting thing about aptitude is that it doesn’t just keep depends of packages, it keeps recommends as well. To see if I could further trim the list of non-auto packages I started looking at the ways to filter the view of packages. I didn’t quite succeed on my own, but after a few emails to the Debian User List I had a nice filter expression:

~i!~M(~R~i|~Rrecommends:~i)

It will show any installed packages that aren’t auto which are dependencies or recommendations of other packages. In short, packages that aren’t marked auto but could (should?) be. Be aware though that circular depends/recommends prevents all packages in that list to be marked auto.

Another cool thing is the “Audit recommendations” view in aptitude. It’s a great way of finding related packages and improving the functionality of the system. If you want to also see the suggests of installed packages you can change the filter in that view to:

!~v!~i(~RBrecommends:~i|~RBsuggests:~i)

By now I’m not too sad that debfoster is being removed, aptitude actually doesn’t suck :-)

[Edited 01-09-2006 17:11 BST] Fixed a few spelling errors.

Del.icio.us backup and restore tool

I’ve finally gotten around to writing tools for backing up (delbackup) and restoring (delrestore) del.icio.us bookmarks. They can be found in the utils directory in the BZR repo for epilicious.

Oh, a word of warning. These tools work fine for me, but they might not work as well for others. You probably should back up your del.icio.us bookmarks before using them (hahaha). Also, restoring is slow due to throttling. A full restore of my 169 bookmarks took me several minutes. If it’s easy I might add some sort of progress indicator.

Epilicious getting famous?

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

Security Now #39

I found the podcast Security Now the other day. (Actually it was before I listened to episode 139 of TLLTS which contains an interview with SecurityMonkey. Well, back to Security Now.) It’s a rather good show which offers good explanations, though rather basic sometimes, on security related topics. Episode 38 was on browser security and the latest, 39, discussed buffer overruns. I found it to be a little too basic at times, but it’s a good starting point for someone who’s interested in security but is finding reading about it difficult. Anyone with a genuine interest should go to Google and do some searching after listening to the podcasts.

Oh, for episode 39 I’d recommend having pen and paper nearby, visualising the stack on a paper will make the explanation so much clearer.