TrashJournal: Your friendly Desktop Raccoon

The Gnome desktop doesn't really have a good view on the trash can. The display in Nautilus is very limited for a number of reasons. Most importantly, it does neither display the original path, nor the deletion date. Thus, it does not allow sorting by deletion date, and you never know where your restored files will end up. Also, if you deleted two files with the same name, there's no way to distinguish between them.

That leaves two choices for the humble user: Keep the trash can in order, or treat it as a black hole.

As a third option, one can use a little Python script that I wrote up recently, which gives a journaled view of the trash can:


Code is (as usual) on GitHub. As it's a Python script, you should be able to just run it (provided that you have Gnome- and GTK+ Python bindings installed).
In fact, if the gconf dependancy was made optional, the script should work on any desktop which conforms to the freedesktop.org trash can spec.

Okay, admittedly, this pet project is basically the result of my wanting to try out GIO, which is actually pretty nice.

Excursion to Packaging-Land

I just pushed a new branch that cherry-picks most of the commits from the split-view branch of Nautilus, but only requires dependancies that are available on a standard Ubuntu Jaunty installation.

More excitingly, I just uploaded packages for this branch for Ubuntu Jaunty to my PPA. The primary reason was to make it easier for me to use the branch at work. But of course, this also makes the code more accessible for Ubuntu users, so I hope for more testing reports.

Nautilus Split View Update

I've been working on cleaning up the history of the my Nautilus split view branch, and basing it on the official git repository. That's done now, so consider this post a call for testing! Grab the source and get it running. Please send emails with bug reports, patches, remarks, and also success stories. I'd also be interested in reports from spatial-mode users, just to make sure the patchset doesn't introduce any regressions for them. I'd really like some more testing before requesting a review upstream.


Some visual polishing took place compared to the old screencast, for example the thin border in the theme's selected-color around the active pane, and shadow around the inactive pane.

The buttons with the greyed-out look in the location bar on the right side of the screenshot are in fact sensitive. Clicking e.g. directory buttons changes to the respective directory and also make that pane active. The grey zoom control widgets and the insensitive-looking background work in an analogous way. That's not exactly HIG-compliant, but it seems very natural and intuitive.

Geo-Tagging

Lately, I had to deal with digital maps at work - a very interesting topic. As I wanted to check out libchamplain anyways, I did a little plugin to display an estimate of the sender's location on a map in Claws Mail. This is a screenshot of one of my mails from a conference which I attended last year:


Of course, there's no way to infer the geographic location of a sender from the mail with any kind of certainty. For example, as mailing list management software tends to rewrite the mail headers, mails to the Claws Mail Users mailing list show up as originated here:



Other mailing lists (like GTK+, or Cairo) work fine, though.

The surprising (and somehow scary) result is that it works on a surprisingly large number of mails (in my quick test, almost half of the time), and if it does, it's oftentimes quite accurate, with deviations sometimes as small as 2 or 3 kilometers. I honestly wouldn't have expected that. The plugin is currently hosted on github, and requires Claws Mail from CVS and libchamplain 0.3.

On a side note: Also on github is an early version of a Gnome plugin, which includes the Gnome address book in Claws Mail's completion list. That plugin crashes on unload, though, which also happens during Claws Mail shutdown. I haven't investigated that in detail yet, but I wouldn't be surprised if that was due to a dependancy library not being plugin safe. Wouldn't be the first time.

Easter weekend coding fun

Had some slack time over the easter weekend, so I was able to do some fun coding.

The Nautilus crew accepted two small patches of mine to deal with keyboard shortcuts. Now it's possible to assign shortcuts to Nautilus scripts, and the shortcuts are remembered accross sessions. That's fixing two long-term annoyances of mine. It landed just in time for Gnome 2.26.1, meaning the Ubuntu Jaunty is shipping the fixes already. Good timing.

The Nautilus split view branch that I have been blogging about (Planet readers: There is a screencast embedded in the previous post) is an ongoing pet project. I consider the branch pretty feature complete, except maybe background color modification of the inactive pane. However, the branch is currently based on an older revision, so the next big thing to do would be rebasing to the current state. In general, I am not hesitating to rebase the public branch on github when appropriate, even though I know that it's bad. Drop me a message if you want to contribute, and that poses problems for you. Anyways, with Gnome moving to git, all that is becomming easier, especially for externals. Did I already mention that git is awesome?

Of course, Claws Mail got some love, too. The notification plugin got support for window manager urgency hints and the fd.o sound specification. It also got a reworked bubble logic, to fix issues with Ubuntu's broken notification daemon. That will be going into cvs once I was able to test with Ubuntu Jaunty. I also wrote a little patch to include Gnome's addressbook in Claws Mail's address completion. The latter is not likely to go into cvs, but I may wrap the patch up and create a plugin for that.

Splitting the Shell ...

... but hopefully without cracking it completely.

Some time ago, I read up on split view filebrowsing in Nautilus, Gnome's desktop shell. The requests, comments, discussions, polls, and flames fill endless bugreports, forums, ideas, articles, and mailing list threads. Well, I am one of those people that like Nautilus, but miss the split view capability during heavy duty filebrowsing jobs. I liked Norton Commander back in the old days, and its numerous successors. And I am not alone.

So, in the true spirit of Open Source, I finally got my hands dirty and got a shot at it. It's not completely finished, but in a state that allows for a screencast preview:



The code is hosted on github:
$ git clone git://github.com/hb/nautilus.git
$ git checkout -b split-view origin/split-view


But will it blend? That is the question.

I am curious if that branch will make it upstream. If you'd like that, you can help with testing and reporting (both, failures and successful uses)! While the patch is UI-wise minimal-invasive, quite a lot of code had to be shoveled around, so I am happy about every tester.

(the beautiful shell picture is by giopuo, published on flickr under Creative Commons by & share alike)

Linux driver nightmare

Linux Hater is right in many of his claims, especially when talking about (non-existing) ABI or even API compatibility of the Linux kernel across versions. Everything is fine as long as your hardware is working out-of-the-box, but as soon as something is not supported out-of-the-box, you're up for a major nightmare.

The past few days, I've been trying to migrate one of our systems from Windows XP to Linux. That box has a few pieces of non-standard hardware installed, mostly sensor systems. Many of those drivers have not found their way into the kernel yet. So let's see..

• Installed Xubuntu 8.04 LTS
• Install kernel headers, build system, etc.
  
• Contact vendor of USB Relais and ask for Linux kernel module
• Surprisingly, got a module that (after minor modifications) compiles and even works!
• Test USB camera. No luck with the Orange iBOT2. Apart from the iBOT2, our framework also supports UVC cameras. Bought a Logitech UVC camera (look out for the "Vista-ready" sticker), which works out of the box in Ubuntu 8.04! Yay!
• Get and compile CAN driver. Seems to work nicely.
• Contact measurement camera vendor, and ask for Linux drivers. Got drivers for a 2.4 kernel. After some investigation, also got experimental drivers for a 2.6 kernel that's been developed on 2.6.13 (and is GPL'ed OSS, btw).
  
• Got the camera driver to compile and load on Hardy's kernel with major modifications. Getting camera info (like chip temperature) works fine, but grabbing images results in kernel panic. Unfortunately, grabbing pictures from the camera is a rather important feature...
  
• Heard rumours that the camera driver works at least up to kernel version 2.6.17
• Try to get kernel packages for something around 2.6.17. No luck on Hardy.
• Clone vanilla kernel git repository, compile kernel 2.6.17. After several attempts, the self-compiled kernel even boots up!
• Compile camera driver again. Grab a first picture! Yay!
• Unfortunately, now the whole rest of the system is pretty broken. Hardy doesn't seem to like a manual kernel-downgrade.
• Got the idea that it might be easier to upgrade a kernel, than to downgrade it. Killed the whole system and installed Xubuntu Dapper 6.06 LTS, which comes with kernel version 2.6.15. Maybe that version will work too, and I won't even need to upgrade..
  
• Compile all external drivers again
• Test if the UVC camera still works. Of course -- it doesn't.
• Download UVC kernel module from svn (there are no snapshots available). Try to compile it -- no luck. Try to find the latest svn revision number that actually compiles with Dapper's kernel by bisection. Compiled and loaded that kernel module.
• Now, let's test with our framework
  
• Oh no -- our framework depends on newer versions of installed libraries (Boost, Qt, etc. pp.) than what is available for Dapper. Grab Boost, Qt, and all other libs from upstream, and compile them.
• Oh no, the cmake build system backported to Dapper doesn't contain all necessary modules either (FindPkgConfig.cmake, others). Get those modules as well. No need to say that the backported cmake build system behaves slightly different to what is installed on Hardy as well.
  
• Compile and start the program. Oh no, crash deep inside Qt. Right -- no OpenGL support without proprietary graphics drivers. Install those as well.
• Test UVC camera. It works!
  

Being a supporter and developer of OSS software myself, I can understand the reasons of the kernel developers for not maintaining a stable ABI (or even API) for kernel modules. But for the user, this is just a major pain, that ultimately renders Linux unusable on many environments.