Linking notes and email messages

A few days ago, I've cobbled together a note-taking solution for my email messages. It's very unixy, consisting of a fair number of different parts working together: Claws Mail with the Python plugin and two of the shipped example scripts on the one side, Tomboy with the Claws Mail addin and the Reminder addin on the other side.

Starting with a message selection in Claws Mail,

a click on the "Create Tomboy Note" menu item of the Python example script results in this dialog popping up (I know that this dialog is ultra-ugly, but hey, it's a quick&dirty easy-code example script, nothing more)

which in turn creates this Tomboy note

The Tomboy reminder plugin will take care to remind me about this next monday by raising the note.

To make the round-trip complete, there's a second example script that raises all Tomboy notes that link to a selected message.

Okay, admittedly not the end-user friendliest setup, but it suits my needs pretty well. And it shows the benefits of scripting language interfaces for glueing components together -- it didn't take long to write the scripts to make this work, even though the plugins and addins have not especially been designed for it.

Extending and Automating Claws Mail - the sneaky way

The recent release of Claws Mail 3.7.4 has also seen a much more powerful version of the Python plugin. It is now possible to write scripts that are executed automatically on startup, shutdown, or opening of a compose window. It's also now possible to write scripts that work on an already opened compose window. The user interface got better as well (e.g. it's now possible to trigger scripts via toolbar buttons).

However, what the latest release still lacks, is documentation and examples. After all, features that are not documented don't exist. This is supposed to get better in the next release. I've started adding a few example scripts to the source distribution that show possible solutions to questions that have been raised on the user's mailing list lately. Most of these should already work with the released version of the plugin, with the exception of the startup script that show's how to add new menu items for custom actions into the main window (the examples being a menu item to mark a thread as read, and to add a menu item to create and show the Python plugin's API documentation on-the-fly - isn't introspection cool?).

Anyways, if anybody scripted something cool with the plugin, please consider sending the (well commented) script to me. I'd be happy to consider it for inclusion in the distributed examples.

The Tomboy and the Beast

To a large degree, Open Source is about scratching personal itches. The results are oftentimes small scripts, tools or plugins, rather than ending up as big projects of their own. Even if only little time is invested, the result can sometimes make a difference in terms of working efficiency. And picking low-hanging fruits surely is fun!

I'm using Claws Mail as MUA and Tomboy to organise my ideas and workflow. Both are truly excellent in their areas. However, an email is oftentimes connected to an idea, or a task, so I want to connect emails and notes somehow. Unfortunately, Claws Mail and Tomboy don't play well together.

When dragging emails from Claws Mail and dropping them into a Tomboy note, this is what you get:

Of course, the temporary files are cleaned up again after Claws Mail is closed, so the links are not only clumsy and non-descriptive, but also non-persistent and therefore totally useless in a note.

No more! I wrote a little addin for Tomboy that provides Claws Mail integration, so when loaded, email drag'n'drop results in this:

When clicking the link, the email is opened in Claws Mail again.

Code is on GitHub. I still couldn't find enough motivation to write the autofoo for it, so for now, a small hand-cooked Makefile has to do. Be sure to read the README file. I am not a fan of binary releases, but if anybody is interested in the dll, drop me a line. Also note that it currently only works with Claws Mail from CVS.

First impression of the Tomboy addin interface was very positive. It makes writing small addins easy, even for those unfamiliar with the general codebase. Well, even more in this case, as Tomboy ships with an Evolution addin which does the same thing for Evolution, and was an obvious source of inspiration.. Isn't Open Source great?

Chronically Underrated: Undo

In the past years, software designers have done a lot of research not only of what a good user interface is supposed to look like, but also how it is supposed to behave. A key component (that to this day a lot of software still gets wrong) is to not bother users with dialogs, especially not those nasty modal ones, but to just do the right thing. Of course, the program can't always know what the right thing is supposed to be, so to accomodate for mistakes, the application should still shoot ahead, but offer an easy way to undo those actions again. The beautiful article "Never Use a Warning When you Mean Undo" by Aza Raskin should be a must-read for all UI developers.

Actually, this not only applies to graphical user interfaces, and clicking away dialog boxes, but also to command line interfaces. I've recently aliased rm with gvfs-trash on a few machines (including my own) for precisely that reason. Unfortunately, this alias does not work completely, but I am still hoping that I can habituate to its limitations.

Unfortunately, Claws Mail is a sinner in that respect, too. On the plus side, it makes it hard to actually loose work (so it's not guilty of Aza's worst software sin). However, in many cases it prevents data loss by distracting the user (by popping up dialog boxes), and makes it hard to revert an accidental operation (like digging up messages in the trash), so it is guilty of Aza's second and third worst software sins. Also, Claws Mail sadly doesn't come with Undo/Redo capabilities at all (well, apart from text entry in the compose window editor).

Some years ago, probably around 2004, I was looking around for a general purpose undo/redo stack that offered GObject integration for a pet project of mine. I was very disappointed to not find anything back then, so I rolled my own. It's a small class that offers undo/redo stacks (optionally with a limited stack size). Stack entries can be grouped, groups can be nested. Everything can have a description. As an optional viewer, I had a simple gtk+ widget to display undo/redo stack entry descriptions in a list (or tree, in case of groups), acting as the view in a MVC pattern. Anyways, in the end, I got distracted from the pet project, and never published it.

So, I thought I could break out the undo class from that old project, clean it up, streamline it a bit, and replace deprecated GObject/gtk+ stuff with shiny new technoligy. While doing that, I was looking around again at available undo frameworks, and was a little surprised to find one for Qt and another one for GObject, both of which I would assume to be older than my class (GUndo's ChangeLog dates back to late 2005, but some copyright headers speak of 1999). I wonder why I haven't found them earlier.. The funny thing is that both are kind of similar to what I did. Especially GUndo is (API-wise) crazily close to what I came up with (but of course, I still like mine better!). I guess there is only a limited amount of reasonable solutions to the undo/redo problem.

We'll see if it's feasible to hook up Claws Mail with an undo stack. It's usually hard to put undo capabilities into a program that hasn't been designed for that from the start. But maybe it'll be possible to put at least a few error-prone actions (like getting back a message that was falsely moved into the trash) in.

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.

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.

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.

Licence fun

If a piece of software wants to link against GPL'd code, it has to be GPL-compatible. To be more accurate, it has to be compatible with that specific GPL version. So far so good.

Now, GPLv2 and GPLv3 are incompatible. As a consequence, code under GPLv2 and GPLv3 cannot be combined. This has nasty consequences.

This time it's not Claws Mail that bites, but it got bitten back by ClamAV. Claws Mail is licenced under GPLv3 or later. It has an optional plugin for email antivirus-scanning that uses libclamav, which is licenced under GPLv2 (only). Do you see it comming? That plugin, even if itself licenced under GPLv2 or later and thus in theory compatible with both sides that it is supposed to connect, is itself illegal.

In fact, you can take the FSF GPL FAQ, section "Combining work with code released under the GNU licenses", read "non-free" or "proprietary" as a synonym for "licenced under GPLv2", and the statements remain valid.

Isn't that ironic, at best?

Now, what is the way out? Colin asked the FSF about the problem, and the options are basically to

• convince ClamAV to put their library under a licence compatible to GPLv3
• have libclamav grant Claws Mail specific permission to link libclamav
  
• change Claws Mail's licence to GPLv2 or later

It is also possible to

• roll out ClamAV's functionality into separate processes (fork(), exec() is legal)
• just drop the ClamAV plugin
  

Fun, isn't it?