Basierend auf Xfce Classic, einem Fork von Xfce ohne Client-seitige Fensterdekorationen.

(übersetzt in de)Shawn Anastasio), ein Enthusiast für freie Software, der einst ein eigenes Betriebssystem ShawnOS entwickelte und sich mit der Portierung von Chromium und Qubes OS auf die Architektur ppc64le beschäftigte, gründete Projekt Xfce Classic, in dessen Rahmen er plant, Forks der Komponenten der Xfce-Desktop-Umgebung zu entwickeln, die ohne die Verwendung von Client-seitigen Dekorationen (CSD) funktionieren, bei denen der Titel und der Rahmen des Fensters nicht vom Window-Manager, sondern von der Anwendung selbst gezeichnet werden.

Erinnere daran, dass im Vorfeld der nächsten Veröffentlichung von Xfce 4.16, deren Release openSUSE/SUSE im Oktober oder November erfolgen soll, die Benutzeroberfläche auf das GtkHeaderBar-Widget umgestellt wurde und CSD angewendet wird, was es ermöglicht, ähnlich wie bei GNOME, Menüs, Schaltflächen und andere Schnittstellenelemente in den Fensterkopf zu platzieren und die Rahmen in Dialogen zu verstecken. Der neue Interface-Zeichnungsmechanismus wurde in die Bibliothek libxfce4ui integriert, was dazu führte, dass CSD automatisch für nahezu alle Dialoge angewendet wurde, ohne Änderungen am Code vorhandener Projekte vorzunehmen.

Der Wechsel zu CSD fand Widersacher, die der Meinung sind, dass die Unterstützung von CSD optional sein sollte und der Benutzer die Möglichkeit haben sollte, klassische Fensterkopfformen weiterhin zu verwenden. Zu den Nachteilen von CSD zählt der zu grosse Headerbereich des Fensters, die fehlende Notwendigkeit, Elemente der Anwendung in den Fensterkopf zu verschieben, die Nichtkompatibilität der Xfwm4-Themes und die Inkonsistenzen im Design von Anwendungen zwischen Xfce/GNOME und Programmen, die CSD nicht verwenden. Es wird festgestellt, dass einer der Gründe, warum einige Benutzer die GNOME-Oberfläche ablehnen, die Verwendung von CSD ist.

Da in den fünf Monaten keine Versuche unternommen wurden, die Unterstützung von CSD abzuschalten, beschloss übernahm Shawn Anastasi die Initiative und erstellte einen Fork der Bibliothek libxfce4ui, in dem er die Bindung an CSD aufräumte und den alten Dekorationsmodus auf der Serverseite (Window-Manager) wiederherstellte. Um die Kompatibilität mit Anwendungen, die die neue API von libxfce4ui verwenden, zu gewährleisten und ABI beizubehalten, wurden spezielle Wrapper vorbereitet, die spezifische CSD-Methoden der Klasse XfceTitledDialog in Aufrufe der Klasse GtkDialog umwandeln. Dadurch wird es ermöglicht, Xfce-Anwendungen von CSD zu befreien, indem die Bibliothek libxfce4ui ersetzt wird, ohne den Code der Anwendungen selbst zu ändern.

Zusätzlich wurde ein Fork erstellt des xfce4-panel, der Änderungen umfasst, um das klassische Verhalten zurückzugeben. Für Gentoo-Nutzer wurde ein Overlay zur Installation von libxfce4ui-nocsd vorbereitet. Für Xubuntu/Ubuntu-Nutzer gibt es für Ubuntu. fertige Pakete. Sean Anastasio erläuterte die Gründe für die Erstellung des Forks damit, dass er Xfce schon seit vielen Jahren nutzt und die Benutzeroberfläche dieser Umgebung schätzt. Nachdem die Entscheidung zur Änderung der Benutzeroberfläche getroffen wurde, mit der er nicht einverstanden war, und es keine Versuche gab, eine Option für das alte Verhalten bereitzustellen, wurde beschlossen, sein Problem selbst zu lösen und seine Lösung mit anderen zu teilen, die seine Meinung teilen.

Zu den Problemen bei der Verwendung von Xfce Classic gehört das Gefühl der Duplizierung von Überschriften aufgrund der Anzeige wiederholter Informationen im Titel und im Anwendungsfenster. Dieses Verhalten entspricht dem von Xfce 4.12 und 4.14 und steht nicht im Zusammenhang mit CSD. In einigen Anwendungen sieht eine solche Duplizierung normal aus (zum Beispiel in xfce4-screenshooter), in anderen ist sie jedoch eindeutig unangemessen. Zur Lösung dieses Problems ist die Einführung einer Umgebungsvariablen, die das Rendering von XfceHeading regelt, nicht ausgeschlossen.

Die Position der CSD-Befürworter besteht darin, den Leerraum in der Fensterüberschrift zu nutzen, um Menüs, Panel-Tasten und andere bedeutende Elemente der Benutzeroberfläche zu platzieren. Gegner von CSD sind der Meinung, dass dieser Ansatz Probleme mit der Vereinheitlichung des Fensterdesigns verursacht, insbesondere bei Anwendungen, die für verschiedene Desktop-Umgebungen entwickelt wurden, die unterschiedliche Empfehlungen zur Anordnung des Kopfbereichs definieren. Es ist viel einfacher, das Design aller Anwendungen in einen einheitlichen Stil zu bringen, wenn die funktionalen Bereiche des Fensters serverseitig klassisch gerendert werden. Im Falle der Verwendung von CSD muss die Benutzeroberfläche der Anwendung separat an jede grafische Umgebung angepasst werden, und es ist ziemlich schwierig zu erreichen, dass die Anwendung in verschiedenen Benutzerumgebungen nicht fremd aussieht.

Quelle: opennet.ru