Das gerade veröffentlichte GIMP 2.99.2 ist die erste Entwicklungsversion, die am Ende dieses Zyklus zu GIMP 3.0 werden wird und damit den endgültigen Umstieg vom GTK2- zum GTK3-Toolkit besiegelt. In der sehr ausführlichen Ankündigung wird betont, dass es sich um eine instabile Version handelt, die noch Fehler beinhaltet.
Wayland und HiDPI
GIMP 2.99.2 bietet unter anderem eine GTK3-basierte Benutzeroberfläche mit nativer Wayland-Unterstützung und schließlich vollen Support für HiDPI-Displays. Neben einem neuen Plugin-API wurde der Quellcode aufgeräumt und einem [wiki title=”Refactoring”]Refactoring[/wiki] unterzogen. Plugins können jetzt in Python 3, JavaScript, Lua oder Vala verfasst sein. Durch Caching für Render-Vorgänge konnte die Leistung verbessert werden.
Grafik-Tablets besser unterstützt
Der Umstieg auf GTK3 zeigt sich dem Anwender zunächst visuell durch eine leicht modernisierte Oberfläche und die Möglichkeit, neu gestaltete Widgets zu nutzen sowie CSD (client side decorations) bei einigen Dialogen. GTK3 bietet aber auch verbesserte Unterstützung für Grafik-Tablets, die jetzt nicht mehr zwingend vor dem Start von GIMP angesteckt werden müssen, sondern Hot-Plugging unterstützen.
Vereinfachtes Theming
Mit GTK3 erbt GIMP auch dessen CSS-basiertes Theming-Format. Damit sind leider alle maßgeschneiderten Themes aus früheren Versionen mit GIMP 3.0 inkompatibel. Positiv zu vermerken ist, dass die Benutzeroberfläche von GIMP mit dem neuen Theme-Format einfacher anzupassen sein wird als bisher. Der Dark-Mode ist in GTK3 verankert und schließt somit alle Elemente ein.
GIMP 2.99.2 unterstützt Wayland zwar, allerdings wurden bereits einige Fehler gemeldet, die bis zur Freigabe der stabilen Version 3.0 bereinigt werden müssen. Darunter sind sowohl Speicherlecks als auch Unregelmäßigkeiten in der Darstellung der Oberfläche. Zudem funktioniert das Skalieren unter HiDPI nicht korrekt. Die Farbauswahl funktioniert mit Wayland unter KDE, aber nicht mit GNOME.
Multi-Layer-Support
Die Möglichkeit der Auswahl mehrerer Ebenen gleichzeitig, die in Zusammenarbeit mit Künstlern und Filmemachern realisiert wurde, soll komplexe Projekte erheblich vereinfachen. Noch kann diese Verbesserung nicht überall eingesetzt werden, da einige Funktionen wie etwa GEGL-Operationen bisher nur eine einzelne Ebene akzeptieren.
Als Flatpak testen
Dies ist nur ein kleiner Ausschnitt der Verbesserungen auf dem Weg zu GIMP 3.0. Für Neugierige, die diesen ersten Entwicklungskandidaten bereits ausprobieren möchten, finden am Ende der Ankündigung eine Anleitung, um GIMP 2.99.2 als aktualisierbares Flatpak zu installieren und somit die weitere Finalisierung verfolgen zu können.
Glimpse, ein Fork von GIMP 2.10.18, strebt unter dem Arbeitstitel Glimpse Redux für 2021 eine Alpha-Version auf Basis von GIMP 3.0 an. Für 2022 ist Glimpse NX angedacht, dass dann auf GTK4 basieren und in Rust geschrieben sein soll.
„eine Anleitung, um GIMP 2.99.2 als aktualisierbares Flatpak zu installieren“ – ich verstehe: Menschen, die es bevorzugen, wenn ihr unixoides System sich nicht wie Windows verhält (= keine .msi-Installer), kriegen keinen Support. Ich zum Beispiel hab gar kein Flatpak…
Zu Glimpse: Schöne Sache, obwohl der Grund für den Fork echt hackedämlich war und bleibt.
GIMP 2.99.2 ist noch instabil. Von mir aus kann das ein flatpak bleiben bis die 3.0 fertig ist. Aber wenn du was schönes malen möchtest kann ich dich gerne mit Buntstiften posix-gerecht Supportieren. 1 Buntstift – 1 Farbe. 😉
Was die praktische Nutzung angeht, verhält sich Flatpak nicht anders als gängige Paketmanager, das ist also nicht wie bei AppImages. Man kriegt die Anwendungen aus einem Repository und zum updaten führt man einfach “flatpak update” aus oder lässt das von Gnome Software etc. machen.
Kann ich mir darunter so etwas wie Chocolatey in Windows vorstellen?
Chocolatey habe ich nie genutzt, allerdings scheint es da vor allem darum zu gehen, Windows einen Linux-ähnlichen Paketmanager zu spendieren.
Flatpak unterscheidet sich vom normalen Linux-Paketmanagement vor allem dadurch, dass die Flatpaks in einer Sandbox laufen und nicht für jede einzelne Distributionen paketiert werden müssen. Alle Dependencies sind entweder in den Flatpaks oder in der dazugehörigen Runtime.
Chocolatey dockt allerdings direkt an Windowsfeatures an und muss nicht alles selbst implementieren.
…und damit werden die Sicherheitsaktualisierungen der Distribution umgangen.
Dafür läuft es in einer Sandbox.
Das ist besser als sich von irgendwo ein tar binary downzuloaden und das direkt in seiner Distribution zu installieren.
Wünschenswert wäre, dass mehr Projektentwickler offiziell flatpaks bereitstellen so wie es Gimp macht.
Der Grund für den Fork ist nicht mehr dämlich als ein Bildbearbeitungsprogramm Gimp zu nennen.
Wie würdest du ein GNU-Programm zur Manipulation von Bildern denn abkürzen?
So eine krude Abkürzung würde ich gar nicht verwenden.
Bei einem Kofferwort mit Image, Photo oder Paint im Namen könnte sich sogar der ein oder andere Durchschnittsnutzer herleiten wofür das Programm wohl gedacht ist.
Es geht aber nicht um Fotos oder um Malen, sondern um Bilder an sich. Und da ist der Name des Programms doch wohl sprechend.
Aber was soll ein Glimpse sein?
Die altbackene Benutzeroberfläche von GIMP ist zwar nicht schön, aber so desaströs wie die (englische) Bedeutung von gimp ist das Programm auch wieder nicht.
Wenn wir neuerdings nur noch Programme haben wollen, deren Abkürzung in irgendeiner Sprache kein missliebiges Wort ist, wird es aber bald eng.
Ein Wort, welches in der Weltsprache Nr. 1 mehrere unvorteilhafte Bedeutungen hat, würde ich persönlich als Programmnamen sehr stark meiden.
Das die Entwickler von GIMP dies anders sehen, spricht genauso für sich wie die altbackene Benutzeroberfläche.
Die Weltsprache Nr. 1 ist Chinesisch. Englisch kommt in den Top 10 aber auch irgendwo vor. Aber, hier kommen wir zum zweiten Problem mit deiner Meinung, es gibt kein Programm namens „gimp“. Es gibt jedoch eines namens Gee I Em Pee.
Sorry, aber ich habe jetzt keine Zeit mit dir auch noch über Weltsprachen zu diskutieren, d.h. ob man sich beispielsweise in Russland, Südamerika oder Afrika besser mit Englisch oder Chinesisch verständlich machen kann.
Also in Frankreich kam ich mit Deutsch weiter als mit Englisch.
https://dict.leo.org/englisch-deutsch/glimpse
Ausschlaggebend dürfte gewesen sein, dass es an GIMP erinnert.
G-l-IMP-se.
Schließlich bezweckt man damit ein Verdrängungs-Wettbewerb.
Da sind Assoziationen als das bessere GIMP beabsichtigt.
Es heißt ja nicht Gimp, sondern GIMP, was für GNU Image Manipulation Program steht. Das ist ein kleiner Unterschied.
flatpak ist besser als ein distributionsspezifisches binary oder tar file das nicht Teil der Distribution ist, also nicht aus dem offiziellen Repo kommt. Denn flatpak Programme laufen automatisch immer ohne zutun des Nutzers in einer AppArmor Umgebung und sind somit vom Rest des Systems abgeschottet.
Und sind nicht portabel – klassisches Vendor Lock-in.
> Für 2022 ist Glimpse NX angedacht, dass dann auf GTK4 basieren und in Rust geschrieben sein soll.
Sollten sie das schaffen, würde ich doch noch eine Chance für das Projekt sehen …
Eine Progranmiersprache ist noch kein Feature.
Ich meinte „Wenn das Projekt es schafft, innerhalb von zwei Jahren auf GTK4 und Rust umzusteigen, würde das zeigen, dass sie doch mehr als nur einen Namen rauspatchen können – aber glaube ich nicht.“
Aber doch, Rust wäre für mich sogar ein „Feature“ – nein, keine Funktion, die man nutzen kann, aber das ist nicht die einzige Verwendung des Begriffs.
Inwiefern ist die Sprache von Bedeutung?
Rust macht es einem schwer unsicheren und nicht parallelisierbaren Code zu schreiben. In Rust geschrieben Programme sind also oft schneller uns sicherer.
Klingt nach einem Problem, das man auch mit fähigen Entwicklern lösen könnte.
Natürlich, aber mit besserem Werkzeug ist es einfacher. Man kann mit einer Axt einen Baum fällen, aber mit der Kettensäge geht es einfacher und schneller.
Trotzdem ersetzt man nicht alle Äxte durch Kettensägen. Weißt du, warum?
Natürlich, und jeder Vergleich hinkt…
Mein Punkt ist halt, das bessere Werkzeuge es den Entwicklern einfacher machen. Warum sollte also jemand der neu anfängt, wie bei Glimpse NX, auf C setzen?
Ich glaube auch nicht das ein Einmannprojekt bis 2022 etwas konkurrenzfähiges zu GIMP wird, aber schauen wir mal.
GIMP mit seine ~1.000.000 Zeilen C-Code wird niemand so schnell umstellen wollen/können.
Wenn dem so wäre, hätte man unsicheren und nicht parallelisierbaren Code im Griff.
Fakt ist nunmal, selbst die besten Programmierer machen Fehler und sie ermüden.
Wenn man sich dieses Interview durchliest merkt man, dass da viel PR im Spiel ist.
Meine Vermutung ist, dass man user auf den neuen Namen vornehmlich auf Windows locken will. Bisher haben sie nur einige Funktion beseitigt und den Windows-Installer schlanker gemacht. Der Rest ist Ankündigung.
Die Strategie erinnert mich an OpenOffice vs. Libre Office.
Danke für den Link, aber in der „Übersetzung“ tut das ja beim Lesen weh! https://daviesmediadesign.com/a-qa-with-the-glimpse-image-editor-development-team/