Claws Mail got bitten by a Snake!

I've been successfully using the Perl plugin for Claws Mail for a long time now. It hasn't seen many updates lately, but that's because I am mostly happy with it for my personal needs.

However, filters for Claws Mail is one of the few remaining areas where I'm still a Perl user. I have the feeling that my mental capabilities are insufficient for memorizing the dozens (hundreds?) of operators, magic variables etc., especially after a while of absense from the language. "There is more than one way to do it" is fine, but with age, I tend to prefer "There is a single (obvious) way to do it" as a motto. So, for all of my scripting purposes, I found a new home at the Python people. Please, no discussion which one is "better", for whatever definition of "better". Both are nice languages, and I guess people just have to figure out which one suits their individual work flow better.

So, lately, I had to embed a Python interpreter in some C code, and, as often when learning about new technologies, I though this might be a fun add-on to Claws Mail. Don't worry, I am not trying to bloat Claws Mail with every single interpreter out there -- although that might actually be a fun experience.

So I cooked up a small Python plugin for Claws Mail, which adds an interactive Python console to Claws Mail (stolen and adapted from gtkparasite - which is a great project). It's also possible to execute scripts from the menu, for further automation. The interface to Claws Mail is still limited, and only includes calling menu items for now.



(Planet readers: A short demo screencast is here).

Code is on GitHub.

PS: Yes, I know that the name Python actually refers to a commedy group, not to the animal. But I don't care.

Update: The plugin source moved to Claws Mail CVS. It also gained on a new trick on the way -- automated composing of mail messages. See the README file for an example.

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)