GIMP und XnViewMP

…oder:

Zwei beharrliche Dilemmata für den Bildbearbeiter

Mal abgesehen davon, dass es immer eine unbefriedigende Situation darstellt, eine bestimmte Software einsetzen zu müssen, weil es keine bessere für den angestrebten Zweck gibt, kann sich eine gewisse Hassliebe zu solcher Software entwickeln, wenn man sich zwar an sie gewöhnt hat, sich aber beständig darüber ärgert, dass sie gewisse grundlegende und für essenziell erachtete Funktionalitäten nicht liefert.

Derlei ist für mich im Moment (immer noch und schon seit ziemlich langer Zeit) der Fall vor allem für die Bildbearbeitungssoftware GIMP, aber auch für die Bildverwaltungssoftware XnViewMP – beide auf (meiner) Linux-Basis.

GIMP

Dieser inzwischen schon alte Klassiker der Bildbearbeitung ist als solcher wirklich enorm leistungsfähig, allerdings fehlt ihm jegliche Möglichkeit, Bilder auch nur wenigstens rudimentär zu verwalten. Hierzu ist grundsätzlich andere (Hilfs-) Software vonnöten. Standardaufgaben wie das Auswählen und Öffnen verschiedener gleichzeitig zu bearbeitender Bilder aus einer Art Katalogansicht heraus – die zusätzlich auch noch verschiedene katalogspezifische Bearbeitungsmodi für Bildergrupoen bietet, gibt es in GIMP nicht. Man benötigt hierfür ein geeignetes Bildverwaltungsptogramm wie z.B. XnViewMP (nur echt in dieser Schreibweise!). Ganz früher verwendete ich hierzu gThumb, das nach meinem Eindruck aber auch irgendwie bei ‚ganz früher‘ stehen geblieben ist.

Ein einfacher Workflow

Der einfache o.a. Workflow sah dann prinzipiell so aus:

Bilderverzeichnis in der XnViewMP-Katalogansicht (mit Verzeichnisbaum!) auswählen, Bilder zum Bearbeiten auswählen, also markieren, [Alt]+1 drücken. Daraufhin startet GIMP und lädt die markierten Bilder in sein Fenster. So gut, so einfach.

Snap… und weg!

Dann stellte Ubuntu seine Software-Paketverwaltung auf Snap um – und die Entwickler packten ihre Software als Snap-Pakete. Das war das Ende des beschriebenen Workflows.

Wesentliches Merkmal von Snap ist das Sandboxing-Prinzip für Anwendungssoftware: jede läuft in einem eigenen Sicherheitscontainer, der keine Dokumentübergaben von und zu anderen Anwendungen zulässt.

Man konnte dieses Problem umschiffen, sofern die Entwickler (wie die von GIM) weiterhin Debian-Pakete (.deb) schnürten, die man einfach außerhalb der Snap-Verwaltung installierte (mit apt). Es ist keine elegante Lösung, weil man dann zwei Paketverwaltungslösungen nebeneinander laufen hat, die die zugehörigen Programm- und Konfigurationsdateien an völlig verschiedenen Orten im Dateisystem ablegen, aber es geht halt.

Inzwischen ist (neben der Flatpack-Alternative) eine weitere Installationsvariante hinzugekommen, die für reine Privatanwender wie mich ziemlich attraktiv ist und gleichzeitig höchst einfach aufgebaut:

AppImages

AppImages sind Software-Komplettpakete, in eine einzige Datei verpackt, die man herunterlädt, irgendwo speichert, ausführbar macht und dann als Anwendung nutzt. Das hat auch den einen oder anderen Nachteil, was aber hier und jetzt nicht von Belang ist. Wichtig ist, dass die o.a. Dokumentübergabe zwischen XnViewMP und GIMP funktioniert.

So weit, so halbwegs gut, zumindest für diesen Mini-Workflow des Starts einer Mehrfach-Bildbearbeitung. Ich habe einen weiteren kleinen Workflow mit Dokumentübergabe, der für mich wichtig ist und bisher bequem zu handhaben war.

Von der Bildverwaltung in den Website-Workflow

Ich publiziere KI-erzeugte Bilder von meinem PC auf einer Online-Plattform (Civitai), in eine ziemlich komplexe, aber IMO gut zu bedienende Webanwendung. Das ging von XnViewMP aus bisher sehr einfach und flüssig:

Ich markierte einfach im entsprechenden Bildverzeichnis die gewünschten Bild-Thumbnails, zog sie mit der Maus (Drag &Drop) ins Browserfenster auf den Import-Button im Image-Post-Bereich, worauf sie dorthin hochgeladen wurden.

Dort werden dann die zahlreichen Generations- und Metadaten dargestellt, teilweise ergänz- und bearbeitbar, ich kann weitere Kommentare dazu schreiben, schließlich den Veröffentlichungszeitpunkt festlegen – und die Bilder veröffentlichen.

Und seit kurzem funktioniert dieser Workflow nicht mehr!

Drag &Drop aus XnViewMP heraus in ein anderes Programmfenster ist nicht mehr möglich. Der Mauszeiger bleibt ein starrer Pfeil und die Thumbnails (oder Bilder in der Vollansicht) verharren an ihrem Ort.

Ermittlungsversuche

Zuerst stellte ich fest, dass es wohl nicht an der aktuellen Version von XnViewMP liegt, die beiden Vorversionen zeigen dasselbe Verhalten. So weit…

Möglicherweise spielt eine Rolle, dass ich erst kürzlich auf die neueste 26.04.1 LTS von Ubuntu aktualisiert habe. Ich kann aber nicht sicher sagen, dass der Verlust des Drag&Drop in XnViewMP genau mit diesem System-Update erstmalig auftrat.

Der kleine erfahrene Problemlösungs-Suchmeister in mir machte sich an die Arbeit und fand — eigentlich nichts.

Ich fand in XnViewMP-Foren auf verschiedenen Plattformen Fragestellungen und Diskussionen darüber, die Drag&Drop-Funktionalität via Maus abzuschalten, da man damit unter Umständen bei unaufmerksamer Bedienung viel Unfug im Verzeichnisbaum anrichten kann. Ja, das ist mir selbst schon passiert. Dass ich aus Versehen mit der Maus ein Verzeichnis nicht nur geöffnet, sondern gleich auch noch irgendwohin verschoben und dann länger suchen musste, um es zu finden.

In den Einstellungen von XnViewMP kann ich Mausbutton-/Tastenkombinationen für Dateioperationen definieren, allerdings wirkt sich das überhaupt nicht auf die nicht vorhandene Möglichkeit aus, Bilder aus der Software mit der Maus herauszubewegen in ein anderes Programmfenster.

Zur Möglichkeit, dass die neue Ubuntu-/Gnome-Umgebung von 26.04.1 LTS, verbunden vielleicht mit der Umstellung auf eine neue Version der GTK-Oberflächen-Bibliotheken oder dem Grafiksystem-Unterbau Wayland, ursächlich verantwortlich ist für diesen Missstand, kann ich im Moment noch nichts sagen, entsprechende Suchen im Netz haben für mich noch nichts zutage gefördert.

Nothilfe

Im Moment bekomme ich meine ausgewählten Bilder nur auf Civitai hochgeladen, indem ich den standardmäßigen Bildbetrachter von Gnome als Drag&Drop-Brücke zwischen XnViewMP und Browseranwendung nutze, Bild für Bild. Das ist ziemlich zeitraubend und lästig.

Und es ist auch ziemlich traurig, denn XnViewMP ist zur Zeit m.W. und m.E. die einzige wirklich leistungsfähige Open-Source-Bildverwaltung auf Linux. Zumindest, was die Gnome-Desktopumgebung angeht.

Ich muss also weiterforschen nach Ursachen und möglichen Lösungen.

Nachtrag am 08. Oktober 2026

Zu XnViewMP

Lösung: Ich habe gestern die neueste Version 1.12.1 installiert (.deb) und kann jetzt wieder Bilder aus dem XnViewMP-Fenster z.B. in den Webbrowser ziehen und ablegen. Was auch immer jetzt die Ursache des Problems und die Methode der Behebung desselben waren, weiß ich nicht.

Dafür war jetzt aber die Frontgröße des gesamten UI der Anwendung auf winzigklein gestellt, auf einem 32″-4K-Bildschirm praktisch unlesbar. Habe irgendwo bei der Lösungssuche gefunden, dass dieser Effekt wohl bei einigen QT6-Anwendungen (unter Wayland?) auftritt. Lösung ist, der Anwendung per Environment-Variable zum Start einen Skalierungsfaktor zur Frontgröße mitzugeben. Dies trägt man in der .desktop-Datei des Programmstarters ein, wie es im dritten Kommentar in diesem askubuntu-Thread im Falle von KeePassXC genau beschrieben wird.