Sunday, August 12, 2012

Nautilus Extra Pane Removal: Myth Busting

Since I announced the birth and the growing-up of Nautilus' extra pane in this blog I guess it's only fair to also mention this feature's silent death here.

There's been a lot of vandalism happening in the repository lately, and unfortunately, the extra pane was one of the victims. But it's in good company, joining type-ahead selection, compact-mode, and the tree sidebar into nirvana.

All these removals came somewhat as a surprise to me, as they seem to directly oppose Nautilus' mission statement. So I guess this has been superseded. Too bad that this wasn't communicated - people would have been less surprised.

So, let's have a critical look at the reasoning for the removal of the extra pane.

Starting with the bug report:

Extra Pane mode was somewhat useful before GNOME 3 had side by side window mode.
Fun fact: That's the first time that I hear a GNOME designer call it "somewhat useful". Usually, the reaction was WE ALL HATE IT (capitals are theirs, I left the double-underline out). Anyways, historically, the extra pane was introduced because of GNOME 3 (see linked mission statement above), not despite of it. Nautilus wanted to make the move from a document launcher to a file manager, because of the GNOME Shell taking over the launcher part. Now, I am not sure where it's moving. File management isn't the focus anymore for sure, looking at all removals combined. It seems the focus is to look pretty. For all those users who start Nautilus to lay back and enjoy its look, as opposed to getting work done. I wonder how many of those exist, outside of the designer world.

That brings us to the most stated reason for the removal of the extra pane: The claim that it has become obsolete due to window snapping. That is just factually wrong.

The main point of the extra pane is to have a default target for file operations. Many operations work on files in two distinct locations: Copy or move files from folder A to folder B. Or from a remote location to the local computer. Or from a USB stick into the document folder. The extra pane introduces this concept of "that other location". So it's possible to get the job done with a single menu item. Or even with a single shortcut key (functionality that was also removed but that I was allowed to bring back).

This inherent connection is the feature that the extra pane offers. It's really a lot different to displaying two random windows side-by-side. That snapping looks somewhat similar doesn't make it a replacement for the feature.

Let me give another example. The inherent connection between the two panes is also available from inside Nautilus Scripts. A have a script that just "diff's the right thing", be it two files in a directory, two files in different directories, or two directories. The script is trivial. With a shortcut assigned to it, these little things help me work. A lot.

Only after somebody showed me this "one key press diff the right thing" feature with window snapping, similarly easy to do and to set up, can he argue that window snapping obsoletes the extra pane.¹

The visual side-by-side display of extra pane is just a nice added bonus to the feature. But even visually it's way better than window snapping:
  • It doesn't need to be full screen. Last time I checked, GNOME was also supposed to be used on desktops - many of which have big screens nowadays.
  • It's easy to get that view, and to get rid of it again. One menu item or button press, instead of mouse placement origies.
  • It has less visual clutter. No double sidebar, no double menu, and so on
  • It's easier to see which pane is selected (actions are applied to the pane that isn't greyed out, genius)
Some of these side-aspects can be taken care of. By horrible hacks, though. Or by removing yet more features. If nothing is left, nothing is duplicated.

C'mon, if you want to argue against the extra pane, you can do better. I mean, if you're on a mission, I'm sure you can think of some more convincing arguments. Let's see...
The combination of panes and tabs is just too much.
And then you decide to move the feature that cannot be handled by window managers into the window manager, and leave the feature that could inside Nautilus? Interesting. In a weird way.
It is inconsistent with the file chooser
In what way? That the file chooser cannot open two panes? Sure, that's because it's a file chooser, not a file manager. By the way, Nautilus has a few features left that the file chooser cannot do either. Like copying and moving files. Or renaming. I see a bright future for Nautilus after you've made it consistent with the file chooser. Or, as has been written in eloquent newspeak: When Nautilus receives yet more "love".

and doesn't work well with touch.
What's wrong with it? And why will window snapping be better? I think it's actually easier to action a menu item than to start and drag-and-drop two windows to snap.

Do you guys actually realize that your whole reasoning consists of either false or unelaborated claims?
We would like to add a more explicit copy/move feature shortly.
I doubt you can introduce the "default target" functionality otherwise in a clearer way. And - even if you could - here's a wild idea: Strip the features out after you have a replacement. Not before.

That's basically it for the bug report and commit msg. But the blog post that I linked to before has more:
The first reason was that it was undiscoverable.
What a reason. Make it more discoverable, then? I thought you were a designer?! Of course, that would mean that you're not on a mission.
this one also stood in the way of providing a better alternative
What alternative? How did it stand in the way? Don't be so fuzzy - where is the beef?
Even if you never used the Extra Pane you always had useless Move To and Copy To items in the menus.
In fact, having these menu items always displayed was a review comment, because that's supposed to be the GNOME way. The original patch only showed them when an extra pane was open. Now, this is brought up as a reason to remove the feature? Funky.
Should we keep the feature for which we have a new and better alternative in Nautilus
We don't have that! I explained it numerous times, but my comments have always been ignored. Provided that you read comments on your own bug reports, you actually know better. Which leaves an ugly after-taste.

I'll leave the side-by-side snapping out, becaues I've covered it already. Which brings me to
and a pile of bugs getting no attention in bugzilla
Now, this is the point that really makes me furious, and that probably makes my mails and posts more explicit than they otherwise would be. The design team has always been badmouthing my work on that feature. It started with "extra pain", claimed that it was "messy code", that "files vanish".² Now, they claim that we had oh-so-many bugs (but of course secret ones, which they won't tell you about).

Of course, I asked dozens of times what's so messy about it. I love being reviewed. Receiving and doing reviews is one of the best ways to learn and advance. However, I never, ever, got an answer.

Which turns the statements from criticism into slander. Disgusting behavior.


Of course, these claims spread over the web, where you can now read all day long that the feature was removed because it was oh-so-buggy and an oh-so-bad hack on top of Nautilus instead of making it properly, and so on.

That's just not true. The extra pane patch (which consisted of about 2000 lines, by the way - for a quick hack I would probably have needed 10 or so) introduced some architectural changes that make sense even if you don't want to have the extra pane. In fact, it would have been smart to keep those, even if the feature was to be removed.

I think I've covered all of the argumentation brought up so far that led to the removal of the extra pane in Nautilus. Not a single item with substance.




1 Fun fact: I like window snapping, too. Actually, I even had a locally patched Metacity on my machine that did snapping somewhere in the middle of GNOME 2 already. It's cool to have Evince and a LaTeX editor open side-by-side, for example. If snapping could have replaced the extra pane, I would have cleaned up that patch and submitted it, instead of putting lots of effort in the extra pane. But I didn't, because snapping cannot replace it.


Edit: When hearing about the "files vanish" part, naturally, I got a bit nervous, and immediately tried to find out what that statement was about. Turned out that there was no data loss, in fact no bug. And the reaction on my inquiry was a huffy note along the lines of "can't we talk without filing bugs?", followed by "what a crappy comment". D'oh.

Monday, May 2, 2011

De-Mail in der Kritik

Was sind die wesentlichen Kritikpunkte an De-Mail? Manche sind einfach beleidigt, dass sie selbst keine größere Rolle spielen, andere haben irgendwie nicht verstanden, wie De-Mail überhaupt funktioniert (was natürlich nicht davon abhält,  dies auf reißerische Art der Welt mitzuteilen). Andere sind da ehrlicher, und argumentieren einfach, dass sie De-Mail nicht brauchen  (was natürlich völlig richtig sein mag, aber wohl kaum als objektives Argument durchgeht).

1. Angriff auf E-Mail und Bezahl-Internet. Das würde ich unter der Überschrift "Verschwörungstheorie" fassen, für die ich keinerlei Anhaltspunkte sehe. Schon alleine die Tatsache, dass De-Mail etwas rein Deutsches ist, macht klar, dass sie normale E-Mail nicht vertreiben könnte oder will. Wenn man E-Mail ausstechen wollte, hätte man auch einen vendor-lock-in eingebaut, und nicht De-Mail extra so kompatibel zu normaler Mail designed, dass der Nutzer die selbe Software für beides nutzen kann. Dann hat man in seinem MUA halt zusätzlich zum GMail, GMX und Hotmail Account auch noch einen De-Mail Account. Dass eine kostenpflichtige Dienstleistung in einigen Teilen des Freibier-Netzes auf wenig Gegenliebe stößt, ist schon klar. Aber am Ende ist ein De-Mail Provider lediglich ein Dienstleister, der einen bestimmten Aufwand treiben und diesen re-finanzieren muss, und - nein, wie schrecklich! - vielleicht sogar ein wenig Gewinn machen will. Ein mündiger Bürger schaut sich Preis und Leistung an, und entscheidet dann individuell, was er in welchem Umfang nutzen will, oder auch nicht. Es mag durchaus Leute geben, die bereit sind, ein paar Cent für belegbare Zustellung einer Nachricht mit belegbarem Inhalt zu bezahlen. Das ist eine Dienstleistung, für die man bisher einen Gerichtsvollzieher beauftragen muß!

2. Technische Schwächen und Mängel. Mir sind bisher noch keine aufgefallen, und es hat mir auch noch niemand welche zeigen können. Was natürlich nicht heißt, das es keine gibt. Also, Butter bei die Fische: Wo sind sie denn nun, die technischen Schwächen und Mängel? Die in diesem Punkt geäußerte Kritik betrifft nicht die technische Umsetzung, sondern die Konzeption, die Verschlüsselung serverseitig umzusetzen. Ich habe es bereits im letzten Blog-Post geschrieben: Es wurde viel versucht, End-zu-End Verschlüsselung populär zu machen. Es setzt sich einfach nicht durch. Ich selbst (als langjähriges Mitglied in einem FOSS MUA Entwicklerteam) habe es nicht mal geschafft, in meinem engsten Familien- und Bekanntenkreis End-zu-End Verschlüsselung zu etablieren. Wenn überhaupt, haben wir hier also einen sozialen Mangel vorliegen. Natürlich ist End-zu-End Verschlüsselung zu präferieren und bestmöglich zu unterstützen, aber wenn Leute proklamieren, dass nur End-zu-End Verschlüsselung akzeptabel ist, dann ist das ein wenig so, als kneift ein trotziges Kind ganz fest die Augen zu, stampft  mit dem Fuß auf und schreit "Ich will aber!". Überhaupt kann die Kritik an De-Mail ja nur sein, dass End-zu-End Verschlüsselung nicht zwingend vorgeschrieben ist - denn unterstützt wird es ja, es wird in den TRs geradezu gepredigt, und Provider werden gezwungen, Infrastruktur für den Schlüsseltausch anzubieten. Obwohl nicht zwingend (weil bei Zwang De-Mail schon im voraus zum Scheitern verurteilt wäre), ist damit die Situation von End-zu-End Verschlüsselung so gut wie nie zuvor: Man hat Zugriff auf identitätsgeprüfte Schlüssel, wenn jemand einen solchen anbieten will. Das alleine ist schon ein großer Fortschritt. Schonmal einem Laien das Web-of-Trust erklärt, oder den Fingerprint am Telefon vorlesen lassen?

3. Rechtliche Einordnung. Hier wird zumindest anerkannt, dass im rechtlichen Sinne die Zustellung von der effektiven Kenntnisnahme unabhängig ist, und zwar unabhängig vom Kommunikationsmittel, sei es normale Mail, Fax, Nachricht auf dem AB oder sonstiges. Klar kann man kritisieren, dass Fristen unter Umständen den einen oder anderen Tag früher loslaufen können, aber wenn ich bedenke, wie oft ich meine E-Mails checke (auch, wenn ich unterwegs bin), und wie oft meinen Briefkasten leere, dann würde ich sagen, ich habe im Durchschnitt mehr Zeit zum Reagieren. In jedem Fall gilt auch hier wieder: Ein mündiger Bürger sollte durchaus in der Lage sein, abzuschätzen, ob bei ihm die Vorteile oder die Nachteile überwiegen. Der einzige Kritikpunkt, den ich nachvollziehen kann, ist die juristische Regelung der Beweislast. Hierbei sollte es nicht weiter schwierig sein, das Versenden einer Mail zu beweisen (signierte Versandbestätigungen sind ja Teil des Systems), aber wie man als Endnutzer den nicht-Zugang einer Nachricht beweisen will, das ist mir schleierhaft. Leider ist die Situation bei Snail-Mail nicht wirklich besser.

Meine generelle Beobachtung der Berichterstattung und der Kommentare zu De-Mail zeichnen leider ein trauriges Bild. Es mag durchaus Punkte an De-Mail geben, die kritikwürdig sind. Diese gehen aber leider in reißerischer Polemik unter, gerne auch gespickt mit Verschwörungstheorien, glatten Falschaussagen und Lügen, sowie gezielter Irreführung von unbedachten Lesern. Das nutzt am Ende niemandem.

Thursday, August 5, 2010

De-Mail: Sinn, Unsinn und Missverständnisse

Da De-Mail in letzter Zeit verstärkt durch die Presse geht, und sowohl Pressemeldungen als auch Diskussionen darüber von vielen Missverständnissen geprägt sind, möchte ich ein paar Gedanken zu dem Thema äußern. 

Was ist De-Mail?

De-Mail ist ein Projekt der deutschen Bundesregierung in Zusammenarbeit mit Service Providern, um einen Beitrag dazu zu liefern, Online-Kommunikation sicherer zu machen. Man beachte den Komparativ in diesem Satz - absolute Sicherheit gibt es nicht, sondern es gibt immer nur Sicherheit gegen ein bestimmtes Angriffsszenario.

Bei der Bewertung von De-Mail sollte man zwischen dem Konzept an sich, der Implementierung dieses Konzeptes und der juristischen Würdigung unterscheiden. Ich möchte hier nur auf das Konzept an sich eingehen.

Wie ist die aktuelle Situation bei E-Mail?

Die beiden wichtigsten Unterschiede betreffen die Datensicherheit und die Zustellungssicherheit.

E-Mails sind wie Postkarten. Jeder, der sie in die Finger bekommt, kann sie lesen, verändern oder sogar verschwinden lassen. Der Weg, den eine Mail durch das Netz nimmt, ist vom Absender nicht beeinflussbar. Außerdem kann prinzipiell jeder eine E-Mail fälschen, also von einem beliebigen Absender an einen beliebigen Empfänger schicken. E-Mail ist damit ein extrem unsicheres Medium.

Es existieren bereits seit langem Methoden, eine E-Mail effektiv zu verschlüsseln und durch eine digitale Unterschrift als "echt" und "unverändert" zu kennzeichnen. Da allerdings das Netz zwischen Sender und Empfänger nicht vertrauenswürdig ist, muss dies Verschlüsselung bzw Signatur direkt beim Absender erfolgen, und Entschlüsselung bzw Überprüfung der Signatur beim Empfänger. Diese Technik wird auch End-zu-End-Verschlüsselung genannt.

Dieses System ist zwar mit aktuellen Mailprogrammen relativ leicht anzuwenden, konnte sich aber leider trotzdem nicht durchsetzen - trotz Förderung von z.B. dem BSI.

Aber selbst, wenn End-zu-End-Verschlüsselung sich durchsetzen würde, könnte damit nicht das Problem der Zustellungssicherheit gelöst werden. Die einzige Möglichkeit für einen Absender einer E-Mail, sich sicher zu sein, dass seine Mail auch angekommen ist, wäre, dass der Empfänger freiwillig eine signierte Empfangsbestätigung zurückschickt. Dieses System basiert also inhärent auf dem Wohlwollen des Empfängers. Ein Äquivalent zu einem (Einwurf-)Einschreiben ist damit nicht umsetzbar. Was nun, wenn ich meinen Mobilfunk-Vertrag fristgerecht kündigen will, aber der Anbieter behauptet, nie eine Kündigung erhalten zu haben? E-Mail ist in dem Fall nicht benutzbar.


Was macht De-Mail nun anders?

De-Mail geht von der Beobachtung aus, dass End-zu-End Verschlüsselung aufgrund des Mehraufwandes bei Sender und Empfänger keine breite Akzeptanz findet. Man baut deshalb ein in sich geschlossenes, vertrauenswürdiges Netz auf, in dem die Nachrichten signiert und verschlüsselt weitergereicht werden. Der Anwender authentifiziert sich also beim Server, und schickt dann seine Nachrichten (bis auf normale Transportverschlüsselung) unverschlüsselt an selbigen. Der Server verschlüsselt und signiert die Nachricht, und leitet sie an den Server des Empfängers weiter. Wenn der Empfänger seine Nachrichten abholen will, entschlüsselt der Server des Empfängers die Nachricht, und reicht sie (bis auf normale Transportverschlüsselung) unverschlüsselt an den Empfänger weiter.

Was wurde also gewonnen? Während früher die Nachricht völlig ungesichert durch irgend welche (eventuell feindlichen) Netze ging, wandert sie bei De-Mail gesichert durch das Netz - und zwar ohne Mehraufwand beim Endnutzer. Es gibt nur noch zwei Stellen, an denen die Nachricht prinzipiell einsehbar und veränderbar ist: An der Schnittstelle ins De-Mail Netz, und aus ihm heraus, also bei den Anbietern von Sender und Empfänger. Diese Anbieter sind aber jetzt nicht mehr irgendwelche beliebigen anonymen Administratoren, sondern Betreiber, die aufwändige Zertifizierungs- und Kontrollprozesse durchlaufen mussten, um überhaupt am De-Mail Netz teilnehmen zu dürfen.

Das ist ohne Zweifel schon mal eine Verbesserung. Was aber, wenn ich meinem Provider und/oder dem Zertifikator (also dem Staat) nicht vertrauen will - wenn ich also noch mehr Datensicherheit brauche? Nun, wenn man niemandem vertrauen will, kommt man um End-zu-End Verschlüsselung nicht herum. Das ist aber keine Einschränkung von De-Mail - zusätzliche End-zu-End-Verschlüsselung bleibt weiterhin möglich, und ist bei De-Mail auch explizit vorgesehen (inklusive Infrastruktur z.B. zum Schlüsseltausch).

Wie siehts bei der Zustellungssicherheit aus? Wie oben beschrieben, ist diese im bisherigen E-Mail Netz nicht umsetzbar. Im abgeschlossenen De-Mail Netz hingegen kann die Zustellung garantiert werden, inklusive signierter Zustellberichte. Man hat also effektiv ein elektronisches Einschreiben. Genau genommen hat man sogar noch mehr, denn man kann sogar den Inhalt der Nachricht, die man versendet hat, belegen (bei Analog-Post wäre das vergleichbar mit der Beauftragung eines Gerichtsvollziehers). Der Mobilfunkanbieter hat nun keine Chance mehr, zu behaupten, meine Kündigung wäre nicht rechtzeitig angekommen. Ich habe also selbst dann einen Netto-Gewinn, wenn ich Verschlüsselung/Signatur selbst mache.

Fazit

Konzeptionell finde ich De-Mail sehr interessant, eine Empfehlung für oder gegen eine Registrierung kann ich aber nicht aussprechen. Dazu müssen neben dem Konzept auch die technische Umsetzung sowie die rechtliche Würdigung akzeptabel sein, und beide Punkte kann ich momentan nicht beurteilen. Noch habe ich keine De-Mail Adresse, und ich weiss auch noch nicht, ob ich mir eine holen werde.

Sunday, February 28, 2010

Nautilus in the stress field between design and function

So, there's been a lot of talk about Nautilus' present and future design. Especially Izo's article collects some interesting proposals for design enhancement that are in my opinion very well worth consideration. It does, however, also contain some points that make me feel a little uneasy.

Naturally, UI redesign comes not only with re-organisation and re-design of existing functionality, but also with omitting of unimportant components. Also naturally, the latter part is tricky to get right, because people don't like it when the functionality that they are habituated to use is suddenly gone, without any accessible replacement. I don't mean to say that UI reduction is impossible, but it's something that has to be considered carefully, according to the focus and target audience of the project. This is a hard process, because individuals or small groups don't necessarily cover all the use-cases that an application wants to address.

Izo seems to have a typical case of forgotten addressed use-cases in his review when he writes about the stop button:
"The stop button. More useful in web browsers, if you want to stop the web browser from loading a page, completely useless in a file manager, where file accessing times are considerably quicker than web browsing times. You simply never have an opportunity to stop the file manager from loading a page. It’s an old relic. I’ve never used the stop button."
That you have never used a stop button in a (network transparent!) file manager does not mean that it's "completely useless". Got the hint in the parentheses? Nautilus does indeed want to support network filesystems, be it NFS and friends or GIO/GVFS mounted stuff. Loading these is actually not too different to what you do with your browser. These can clearly be very slow, and that you didn't think of that just shows that you forgot an important use-case that Nautilus wants to support, because you have no personal use for it.

Now, I am not saying that the stop button is the best design for that. It most probably isn't. One could for example test if it could be combined with your proposal of the "refresh" button: Display the "refresh" symbol when the displayed location is fully loaded, and put a little stop symbol there while it's loading (this combination of stop/refresh has been proposed before in "Simplified Nautilus").

People are different, and have different ways to use applications. Many other proposals, for example, just assume that the sidebar is visible. You mean to save a little bit of screen space by omitting the small "Home" toolbar button, arguing that it's also accessible in the sidebar? Well, when I look around, a fair number of computer-novices that I see don't have the sidebar visible at all. When forcing it upon them, they actually loose a lot of screen estate, and have a lot more unwanted UI elements in their face. Combine that with the talk about removing the menu bar alltogether (and thus loosing the habituated easily accessible way to toggle the sidebar visibility), and you have a good potential to regress usability for a non-negligible part of your target audience. In the end, people don't open Nautilus to lay back and enjoy its look, but to get work done.

I am also not entirely convinced that it's so bad to have two toolbars. I mean, how much screen estate do you loose, in reality? For one thing, the toolbar covers less space than the sidepane. In browser mode, you typically don't have dozens of Nautilus windows on a single workspace (and as I said, the toolbar covers less space than the sidepane). On the other hand, even if you have reduced the number of toolbar buttons to six plus a wide-enough search window, as your mockups show, what's better: To use a few vertical pixels, or not to be able to see your current folder "Pictures from Patrick's wedding where aunt Maggie got really drunk"? Hard to say.


Split View - Curse or Blessing?

Having the location bar embedded into the toolbar items also has another problem: It doesn't work well with the a split-view filebrowsing mode. This mode got some very harsh criticism at the recent designers hackfest that I stumbled upon by coincidence (strangely, this discussion didn't find its way to Nautilus communication channels yet). I wrote some comments on the corresponding blog posts, but I also want to write a small comment about that here on my own webspace, without the risk of being moderated (as seemed to have happened on other people's digital homes, which obviously found my remarks unpleasant).

First of all, I am disappointed by the way the criticism was expressed. The designers may very well have some valid points, but I wouldn't know, because they seem to actively refuse to answer my request to elaborate on their non-descriptive slating. Also, there are some remarks that make it look like they didn't even give it a fair try before condemning it.

A reccurring question was "why split-view", and the proposal to implement panes in the window manager instead. This is a valid question, and has in fact been discussed on the Nautilus mailing list. (Hint: In general, project mailing lists are a good place for both, to research design decisions and to ask the "why" question.)

Fact is, split-view filebrowsing is not trying to solve window manager shortcommings on the wrong level. Even if Metacity had snap today, this wouldn't be an alternative.

The key difference is the inherent connection between those two panes, which gives clear benefits. When you want to do file management (which is now becomming the key-focus of Nautilus), you often have to deal with two locations at the same time: The source, and the target. What split-view does is to display a "default target" right next to the source. That's why it makes sense to have 2 panels, but not 3 or 4.

This default target is accessible in the menu, via the "{Copy| Move} to other pane" items. Users that need to do heavy-duty file handling can assign keyboard shortcuts to those menu items, and move around files with a single button press.

The “default target” notation offers even more for advanced users, which can access both the source and the target pane in their Nautilus Scripts (and write for example a “diff these two directories” script with very little effort). This surely isn’t possible with a WM snap either.

Users with simpler needs aren’t really affected much by of all this. The only effect for them is that “extra pane” option in the view menu that they don’t wanna click.

I actually think that it is a very natural model to show source and target location when they are that fundamental to the typical action that the user wants to do with a given application. I find it much more intuitive than the clipboard copy/paste stuff that is generally accepted because people got used to this strange idea.

Photo © Adventures in Librarianship on flickr, cc-by-nc-sa

Friday, February 26, 2010

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.

Monday, January 18, 2010

The Tomboy and the Git

Tomboy's taming of the beast turned out to be a very useful feature for my daily note keeping. But emails are not the only pieces of information that I often find associated with tasks. Another recurring source that I want to reference are commits in source code management systems. So, if Tomboy can play nicely with my MUA, why shouldn't it play nicely with my source code repository browser as well?

Unfortunately, there's no drag-and-drop target for git repository viewers defined. Most viewers just don't let you drag from the commit list into another application. So, I tried to contact the guys from gitk, giggle, and gitg in the hope to define such a dnd target. The guys from gitg seemed to be the only ones interested in that functionality (good thing that gitg is currently my favorite browser anyways), and it didn't take long until they added the required features.

With that in place, it was easy to write a Tomboy addin that handles dropping of git references into a note analogous to dropping email messages: By creating a link with a nice icon and a meaningful text which when clicked opens the git repository viewer and selects the respective commit.



I like these little helpers. They have a good work/gain ratio.

Sunday, January 17, 2010

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.