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: , , ,