© photocase.com

Je mehr Daten ein Computerbenutzer hortet, umso schwerer fällt ihm das Wiederfinden. Die richtige Kategorisierung ist dafür eine wichtige Voraussetzung. Das noch etwas fragile Leaftag bietet für diesen Zweck Kategorien-Tags – unabhängig vom Dateisystem.

Hierarchische Dateisysteme sind ja gut und schön. Ab einer gewissen Zahl an Dateien helfen aber auch sie nicht mehr Ordnung zu halten. So mag es eine Zeit lang gut gehen, für Sammlungen mit digitalen Bildern Verzeichnisse zu verwenden, die für inhaltliche Kategorien stehen, zum Beispiel Natur, Technik oder Menschen. Weitere Unterverzeichnisse stehen dann für Verfeinerungen wie im letzten Fall Familie, Freunde, Arbeit und so fort. Wenn Bilder in mehrere Kategorien fallen, löst mancher Anwender das Problem mit symbolischen Links. Das Wiederfinden wird dadurch aber auch nicht unbedingt einfacher.

Ordnung durch Tags

Eine bessere Lösung dieses Suchproblems versprechen Ansätze, die Metadaten für Dateien vorsehen. Der Anwender fügt dabei Schlüsselwörter zu jeder Datei hinzu, die er später zum Wiederfinden verwenden kann. Mit solchen Metadaten lässt sich eine Ordnungsstruktur schaffen, die abgekoppelt vom Dateisystem funktioniert. Ein Beispiel dafür ist die Bildverwaltungs-Software F-Spot [1], die Fotos mit so genannten Tags ordnet (siehe Abbildung 1). Damit erlaubt das Programm neben der zeitlichen Anordnung der Bilder auch die Sortierung nach Kategorien.

Abbildung 1: F-Spot verwendet Tags zur Kategorisierung der Fotos. Allerdings stehen sie nur innerhalb dieses Programms zur Verfügung.

Leider funktionieren die Tags nur innerhalb von F-Spot. Praktischer wäre es natürlich, wenn solche Meta-Informationen in allen Programmen zur Verfügung stünden. Diese Idee hatten auch die Programmierer des Leaftag-Systems, das systemweite Metadaten für Files implementiert [2]. Vater des Projekts ist Christian Hammond, der sonst bei VMware arbeitet. Einiger Gnome-spezifischer Code stammt von David Trowbridge.

Haarige Installation

Leaftag steckt noch in einem relativ frühen Entwicklungsstadium, die Tagging-Funktionalität funktioniert aber bereits problemlos. Das Leaftag-Projekt besteht aus vier Teilen: der C-Bibliothek Libleaftag, den Tagutils und den beiden Gnome-spezifischen Paketen Leaftag-Python und Leaftag-Gnome. Fertige Pakete gibt es bislang für keine Distribution, deshalb muss der experimentierwillige Anwender selbst zum Compiler greifen. Leaftag setzt verhältnismäßig wenige aktuelle Bibliotheken voraus, auch keine CVS-Versionen oder Ähnliches. Wer die Leaftag-Unterstützung für Gnome installieren will, braucht mindestens Gnome 2.12 mit den Entwicklungspaketen.

Nach dem Herunterladen der vier Pakete von [2] muss man zuerst die Libleaftag übersetzen und installieren, denn die anderen Pakete bauen darauf auf. Die Übersetzung läuft – wie bei anderer Autoconf-verwalteter Software auch – zuerst über das Skript »configure«. Libleaftag speichert die Kategorien-Tags in einer SQLite-Datenbank. Deshalb müssen die Entwicklungspakete von SQLite in Version 2 installiert sein, SQLite 3 ist nicht API-kompatibel.

Wer Configure ohne weitere Optionen ausgeführt und die Dateien mit »make install« auf der Festplatte verteilt hat, sollte die Umgebungsvariable »PKG_CONFIG_PATH« für die weiteren Pakete auf »/usr/local/lib/pkgconfig« setzen. Sonst finden sie die Datei »leaftag.pc« nicht, die das Installationsskript dorthin kopiert hat. Leaftag-Python setzt noch die Entwicklungspakete für Python-GTK voraus, bei Fedora 4/5 ist das »pygtk2-devel«, in Ubuntu »python-gtk2-dev«.

Am aufwändigsten ist es, die Voraussetzungen für Leaftag-Gnome zu erfüllen. Es erfordert nämlich das Deskbar-Applet [3], das es zwar für einige Distributionen gibt, aber nie in einer halbwegs aktuellen Version. Also bleibt wieder nur herunterladen und selbst kompilieren. Dazu wiederum braucht der Fedora-Benutzer mindestens das Paket und »gnome-python2-applet«, für Ubuntu »python-gnome2-dev«. Nach der Installation des Deskbar-Applet sollte sich Leaftag-Gnome übersetzen lassen.

Damit das Deskbar-Applet sich ins Gnome-Panel integrieren lässt, sind noch ein paar weitere Schritte nötig. Ohne Angabe eines Configure-Präfix landet das Applet unterhalb von »/usr/local«, wo der Bonobo-Server normalerweise nicht nachsieht. Den Pfad in die Konfigurationsdatei »/etc/bonobo-activation/bonobo-activation-config.xml« einzutragen funktioniert am besten mit dem entsprechenden Utility:

bonobo-activation-sysconf --add-directory=/usr/local/lib/bonobo/servers

Damit das Deskbar-Applet im Applet-Menü auftaucht, ist es nötig, die entsprechenden Komponenten zu beenden, woraufhin sie selbst neu starten:

killall bonobo-activation-server
killall gnome-panel

Am Ende bleiben nur noch die »tagutils«, die das gleichnamige Programm enthalten, um Dateien mit eigenen Kategorie-Tags zu versehen. Es kennt selbst fünf Kommandos, die hinter dem Befehlsnamen stehen: »ls«, »tag«, »tagprop«, »tags« und »untag«. Um ein neues Tag anzulegen, ist nicht mehr erforderlich, als eine oder mehrere Dateien damit zu versehen: » tagutils Familie Bild.jpg«. Statt einer lokalen Datei kann der Anwender auch eine URL angeben und damit also auch nicht-lokale Ressourcen taggen. Die Kombination »tagutils untag Tag Datei« entfernt einen Tag-Namen wieder. Natürlich ist es möglich, einer Datei mehr als ein Tag zu geben. Dazu führt man das Tagutils-Kommando mit den gewünschten Tags aus.

Wofür die Properties gut sind, die sich über »tagutils tagprop« zu jedem Tag anlegen, auslesen, verändern und löschen lassen, ist nicht ganz klar. Vorhandene Properties wie »description«, »hidden« und »image« zeigen aber die Richtung an: Programme, die Tags verwenden, können davon Gebrauch machen, um Beschreibungen und Bilder zu den Kategorien anzuzeigen oder einzelne Tags ganz zu verbergen.

Eine Liste der verwendeten Tags liefert »tagutils tags«. Die Möglichkeit, Tags zu löschen, besteht bisher nicht. Die mit einem bestimmten Tag versehenen Dateien und URLs gibt die Kombination »tagutils ls Tag« aus.

Hinter den Kulissen

Allzu schwer haben es sich die Programmierer nicht gemacht. Sie verwenden eine SQLite-Datenbank (»/.tags.db«), um in drei Tabellen die Dateien, die Tags und ihre Zuordnung zu verwalten (Abbildung 2).

Abbildung 2: Hinter Leaftag steckt eine SQLite-Datenbank. Das Daten-File findet sich unter »$HOME/.tags.db« und enthält die drei Tabellen »sources«, »tags« und »assocations«.

Als Schlüssel dienen zudem nicht etwa Hashsummen oder Ähnliches, sondern einfach nur der Dateiname. Diese Lösung ist nicht allzu robust, denn wenn sich der Dateiname oder -pfad ändert, findet Tagutils das File nicht mehr. Das Kommando »tagutils ls Tag« gibt bei der Suche auch keine Fehlermeldung aus, vermutlich, um in GUI-Frontends hässliche Fehlermeldungen zu vermeiden. Verschiebt man nach dem Taggen verschobene Dateien an ihren alten Ort, findet Tagutils sie wieder – die Datenbank bleibt unangetastet.

Es stellt sich die Frage, wie eine bessere Lösung aussehen könnte. Einige Kommentatoren haben auf der Leaftag-Site – nahe liegend – Extended Attributes der Dateisysteme vorgeschlagen, die aber mehrere Probleme mit sich bringen. Einmal sind sie nicht portabel, gehen also beim Transport von Dateien auf andere Rechner verloren. Zum anderen gelten Extended Attributes immer systemweit, erlauben also keine rein benutzerspezifischen Tags.

Eine andere Möglichkeit wäre, den Leaftag-Weg zu gehen und alle File-Utilities oder die VFS-Schichten von Desktop oder Kernel so zu verändern, dass sie stets die Datenbank aktualisieren. So ähnlich verfährt Apple mit den Dateiressourcen auf Mac OS X, die es allerdings nicht zentral, sondern dateiorientiert in versteckten Verzeichnissen ablegt.

Trotz dieser Schwächen haben einige Gnome-Projekte Leaftag bereits begeistert aufgenommen. Bei der aktuellen Architektur muss jeder Programmierer, der Tags benutzen will, die Unterstützung in seine Software einbauen. David Trowbridge hat das versuchsweise mit Gimmie gemacht, einer Art persönlichem Informationsmanager für Gnome. Das Demofilmchen dazu findet sich unter [4]. Auch der moderne Notizenmanager Tomboy beherrscht testweise die Leaftag-Kooperation [5].