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.

Reactions to the Debian - OpenSSL - disaster

I really wanted to abstain from commenting the Debian OpenSSL disaster. I have however read far to many false claims and bloodcurtling comments to leave them uncommented.

Clearly, the Debian's OpenSSL maintainer has messed up seriously. Very seriously. He is the one to blame for thousands of machines being easily attackable during a time period of about 2 years.

It's not as if the OpenSSL team was unblamable of this misery though.

• The original query of the Debian Developer resulted in an unfortunate answer of an OpenSSL team member, and other than that ignorance. Another mail about a year later clearly says that a patch commenting out those lines made it into Debian, again with no feedback, so even the "If OpenSSL had known that this should go into Debian..." argument is invalid. I wonder why, since an OpenSSL guy claims that this mistake is so obvious and that upon seeing the patch, "we (the OpenSSL Team) would have fallen about laughing, and once we had got our breath back, told them what a terrible idea this was."
  
  I am not going to comment on the the claim that openssl-dev was the wrong mailing list, as Branden's blog post leaves nothing to add on that topic.
  
  
• The claim that making OpenSSL Valgrind-clean is just a minor, unimportant cosmetic fix is wrong. The OpenSSL library is typically used by programs with network access. The developers of these programs often use Valgrind to catch memory access failures, which could easily compromise the security of the machine if not detected. Being able to Valgrind your code without drowning in OpenSSL warnings and errors is an important thing.
  
  Using very questionable (see point below) constructs in the code without even a source code comment is not something to be proud of either.
  

• The claim that the original OpenSSL code is not buggy is wrong. The claim that the "harmless" part of the disastrous patch is just harmless is wrong. It fixes a serious bug in OpenSSL. Using uninitialised objects with allocated or automatic storage results in undefined behavior in C.
  
  It may add Entropy to the pool. It may crash. It may send out a tarball of your .ssh and .gnupg directories to ronald@mcdonald.com without letting you know.
  
  All three options (and any other option) is completely valid at program run time, or even at compile time.
  
  For example, this is a program that I use to predict the lottery numbers of the next five years:
  
  #include <stdio.h>
  
  int main()
  
  {
  
  int a;
  
  a++;
  
  printf("%d\n",a);
  
  return 0;
  
  }
  
  
  What? This doesn't work for you? Welcome to the wonderful world of undefined behavior.
  
  In the light of this, above linked comments sound almost ironic.
  

I feel Debian has learnt a lesson out of this. Can the OpenSSL team say the same?

Disclaimer: These are solely my oppinions. I speak for no project or company or whatever. I am in no way affiliated to either OpenSSL or Debian. Both are outstanding, impressive free software projects.

Claws Mail goes OpenSync - progress report

It's been a while since my initial announcement of the Claws Mail - OpenSync connection. Addressbook and calendar synchronisation are a pretty important topic for me. I hate trying to keep all those addressbooks or calendar events on PDAs or cell phones in sync manually. It is a lot of hassle - and ultimately just doesn't work.

The OpenSync guys came up with a pretty well thought-out synchronisation framework that sounded interesting enough to invest some rainy Saturday afternoons and hook up Claws Mail with it.

Now that contact synchronisation is going better and better, I decided to make my hands dirty on calendar events as well. Colin, being the author of Claws Mail's vCalendar plugin, helped me out and implemented part of my calendar interface wishlist in the vCalendar plugin. As a result, one-way syncs of calendar events from Claws Mail to OpenSync counterparts are possible.

As a proof of concept, let's use a Claws Mail / EDS sync group to show upcomming calendar events in the GNOME clock:


It's far from being complete (and even farther from being usable), but it's an encouraging progress.

Hosting moved to github. There's one repository for the OpenSync plugin for Claws Mail, and another repository for the Claws Mail plugin for OpenSync. You'll need both if you want to try this out. Also, the plugin for OpenSync requires a pretty recent (probably svn) version of OpenSync up and running.