Und wieder einmal ist es soweit ūüôā
Version 0.1 einer neuen Software ist geschl√ľpft.

Aufbauend auf meinen Erfahrungen mit dem eher akademischen Experiment “kio-clipboard” habe ich mich diesmal an etwas versucht, was vielleicht sogar einen realen Wert haben wird. Oha!
Wie auch beim Vorg√§ngerprojekt und wie aus dem Namen schon ersichtlich dient auch diese Software als Plugin in den KDE-Desktop. Ich will hier nichts weiter zu den Gr√ľnden f√ľr die Wahl dieser Plattform sagen. Gerne in einem anderen Umfeld ūüôā

Worum geht es hier ?

1.) Motivation:
Wenn es darum geht, Bilder, Photos im Web zu präsentieren, also zu veröffentlichen, dann gibt es derzeit grob drei Alternativen:
i.) traditionell, einfach, kurzsichtig: versenden als Anhang an einer Email, Generieren eines ZIPs, PDFs, DeJaVus, … dass dann ebenso verbreitet wird
ii.) Hinterlegen auf einen kommerziellen Dienst (egal ob der kostenpflichtig ist oder nicht) und verschicken eines Links
iii.) nutzen einer freien Alternative wie ‘ownCloud’ oder ‘Gallery’
Ich selber nutze seit Jahren die ‘Gallery’ Software: ein klassisches Projekt, dass eine stabile, kontinuierlich weiter entwickelte Plattform bietet. Gallery2 (Version 2) bot eine Unmenge an M√∂glichkeiten, Plugins, Themes, etc etc. Durchaus begr√ľndet wurde Gallery3 (Version 3) abgespeckt, aufger√§umt, vereinfacht. Alles ist klarer, schlichter und besser, Allerdings fehlen auch ein paar Aspekte. Darunter auch die Vielzahl der M√∂glichkeiten, wie man Bilder importieren kann. Gallery3 bietet noch genau 2 Alternativen: einen flash-basierten Uploader, der bei mir schlicht gesagt einfach nicht funktioniert (die ewigen flash-Probleme, nicht Gallery3-Probleme) und einen einfachen HTML-Uploader. Der funktioniert, ist aber so 80ish, so nervig einfach, so langsam und Umst√§ndlich in der Nutzung.
Gewohnt ist man heute das intuitive Drag’n’Drop zum Verschieben von Dateien, seit es zuverl√§ssig nutzbar wurde auch √ľber Applikationsgrenzen hinweg. Aber es geht noch einen Schritt weiter, eines meiner Lieblingsthemen: “Netzwerktransparenz”. Warum √ľberhaupt unterscheiden zwischen dort (“auf dem Server”) und hier (“im lokalen Dateisystem”) ? Ist doch nur l√§stig. Warum kann ich Dateien auf einem Server nicht einfach √∂ffnen, √§ndern und speichern ? Und zwar generell, prinzipiell, nicht nur in einer einzelnen Applikation, deren Autor nun gerade ein bestimmtes Protokoll f√ľr w√ľrdig befunden hat, es zu unterst√ľtzen. Also grunds√§tzlich mit allen Applikationen. Ja klar, zu sch√∂n um wahr zu sein, kann ja gar nicht gehen ? Na klar kann es: genau das ist einer der zentralen Ans√§tze des KDE-Desktop (verf√ľgbar f√ľr Linux, MacOSX und MS-Windows): konsequente Integration und Transparenz im Gegensatz zur heute allgegenw√§rtigen Separierung. Reaktionsschnelle Richclients anstelle hakeliger Webapplikationen, und das ohne Verzicht auf Netzwerkintegration. “Social Web” und “Sematic Desktop” done right. Aber ich schweife ab…

2.) Umsetzung:
“kio-gallery3” integriert Gallery3-Systeme transparent in das lokale Dateisystem. Also kann man den Inhalt von Gallery3-Systemen nutzen wie lokale Dateien, also etwa mit lokalen Applikationen. Und man kann lokale Dateien einfach in Gallery3-Systeme hoch laden. Einfach durch Drag’n’Drop oder auch simple Dateioperationen wie “Datei speichern unter…”. Logische Anwendungen sind also der Zugriff auf Bilder einfach per Dateimanager, das Hochladen aus der eigenen Photoverwaltungssoftware schlicht per Speichern und das Ablegen eines Shortcut auf dem Desktop, der eine lokale Applikation wie eine Slideshow startet.

3.) K√ľnftige Ziele:
es gibt eine Reihe k√ľnftig denkbarer Erweiterungen, die im ersten Release bewusst zur√ľck gestellt wurden (Eric S. Raymond: “release early”).
Darunter sind interne Aspekte wie Beschleunigung der Preview durch ein G3-Plugin im kio-thumbnail slave, aber auch zus√§tzliche F√§higkeiten die √ľber reines Dateimanagement hinaus gehen. Etwa das √Ąndern von Kommentaren, die Assoziation zu Tags oder schlicht die Kontrolle √ľber Titel von Bildern und deren Reihenfolge der Darstellung.
Weiter klappt es vielleicht, die Performanz f√ľr die F√§lle zu steigern, dass eine neue Appliaktion (oder besser ein neuer Slave) gestartet wird: etwa wenn man in einer Liste von Bildern ‘√Ėffnen mit Gwenview’ w√§hlt. Das funktioniert, aber der zus√§tzliche Slave muss derzeit erst einmal im Hintergrund die gesamte Hierarchie bis zum gew√ľnschten Objekt lokal nachziehen. Das liegt an der Logik der API, die Gallery3 bietet. Diese ist sehr schlank, pr√§zise und gut erweiterbar. Sie wehrt sich aber ein wenig dagegen, in klassischen Verzeichnis-Hierarchien genutzt zu werden. Ein direkter Sprung in die Tiefe der Albenhierarchie ist nicht m√∂glich. Ich denke hier in Richtung auf eine Verlagerung des Hierarchie-Caches in einen Shared-Memory-Bereich und eine zus√§tzliches KDED-Modul als Mittelsmann zwischen mehreren Slave-Instanzen.
Interessant w√§re nat√ľrlich auch die direkte Integration in andere Applikationen, etwa das geniale ‘digikam’. Zwar k√∂nnen solche Applikationen einfach durch das Dateimanagement auf die hier gebotenen Funktionen zur√ľck greifen. Eine engere Integration kann aber sicherlich bessere Ergebnisse erzielen, etwa eine funktionierende “Export nach Gallery3”-Funktion.

4.) Butter bei die Fische !

Die offizielle Veröffentlichung findet sich auf kde.org bzw. opendesktop.org
Installation am einfachsten durch einmaliges Einbinden meines OBS-Repositories in die lokale Softwareverwaltung. Dann einfach nur das Paket “kio-gallery3” zur Installation ausw√§hlen und best√§tigen. Download, Abh√§ngigkeitspr√ľfungen und Updates funktionieren dann automatisch und sicher. So soll IT sein ūüôā
Alternativ k√∂nnen fertige Source- oder Bin√§r-Pakete auch direkt von OBS per Browser herunter geladen und manuell installiert werden. Quellpakete sind nat√ľrlich auch auf meinem Source-Repository verf√ľgbar.

Wie sieht das denn nun aus ? Bilder sagen mitunter mehr als Worte:

Konqueror with open file dialog, opened ‘places’ shortcut

Dolphin Filemanager accessing Gallery3

Have fun !

Tags: , , ,