Openbox versus Gnome

Eine knackige Zusammenfassung finden Sie in Textform und im Video „Zack Zack“ (Dauer rund 5 Minuten) mit der Frage: Wozu ist GNOME nütze?

Kritik an Entwicklungen im Design unter Gnome und von Programmen (Anwendungen), die von oder für Gnome geschrieben werden und Einfluss auf das Design von Distributionen und von Programmen (Anwendungen) jenseits von Debian-Gnome nehmen.

Video: Möglichkeiten der Anpassung von Programm-Fenstern mit Hilfe von Openbox – und die fehlende, geradezu geraubte Möglichkeit der Anpassung der Programm-Fenster unter Gnome.

Es ist ein grundsätzlicher Fehler in der Entwicklung von Design, wenn die Funktionen von Programm-Fenstern nicht unterschieden werden von den Funktionen der Programme. Genau dies aber zeitigt die Entwicklung des Debian-Gnome-Designs.

Videos aus 2023 überarbeitet in 2024

Halten Sie die Videos an, wenn Sie in Ruhe vorkommende Texte lesen wollen …

Handhabe es aber in diesem und in allen folgenden Videos besser so, dass ich weniger Text „mit Ihnen lesen“, sondern mehr in den Videos zeigen will; und die Videos entsprechend insgesamt kürzer halten will – also „zackiger“ …

Video:

Im Video gegen Ende taucht der Begriff „Toolbar“ auf – es hätte „Notebook“ dort stehen müssen.
Es wird aber im Video deutlich gemacht, was gemeint ist.

Zwei Videos –
Arbeiten mit Programmfenstern unter Openbox, Beispiele.
Designvarianten via Openbox, zwei, drei Beispiele hinsichtlich Funktionalität und Design.
Funktionalität Programmfenster und Arbeitsflächen unter Openbox im Vergleich zu Gnome.

Videos – Arbeiten mit Openbox:

Ein gewisse Wiederholung im folgenden Video (rund 5 Minuten) – dennoch zeigt es weitere Einblicke, was unter Openbox möglich ist – und unter Gnome nicht.

Ich habe in diesem Video nichts an meinen Einstellungen (Design) geändert – es zeigt also meine „reale“ Arbeitsumgebung. Sie machen es dann anders …

Funktionen von Programmfenstern

Soweit, so banal.

Soweit, so banal?

Wichtiges und weniger Wichtiges

Für mich ist die Nennung des Datei- und / oder Ordnernamens sowie deren Pfade wichtig.

Insbesondere bei eingerollten Fenstern zeigen diese Informationen sofort den Inhalt.

Die Nennung des Programmnamens (und der Versionsnummer) ist hilfreich, jedoch vielleicht weniger relevant wie die Nennung des Datei- und / oder Ordnernamens (oder des Namens einer geöffneten Website im Browser).

Das Symbol des Programms halte ich für keinen Ersatz für die namentliche Nennung des Programms.

Mich selbst stören Symbole sowohl in den Programm-Titelleisten wie in Menüs.
Durch die Orientierung an Text helfen mir Symbole wenig, ich „interpretiere“ und „übersetze“ sie nur unnötig, was ein geschriebener Name mir gleich klar vermittelt, für den das Symbol ja stehen soll.

Bei der Vielzahl derzeit kursierenden Symbole halte ich es für keine gute Idee, textuelle Namen durch Symbole ersetzt zu sehen – also, ich kann mir die ganzen Bedeutungen all dieser Symbole nicht merken.
Dies mag dann auch die Begründung dafür sein, dass Symbole häufig eine textuelle Klärung via „Tooltip“ bekommen.

Nun ja, da ist mir ein klarer Name auf den Titelleisten geöffneter (ggf. eingerollter) Fenster aussagekräftiger, für jede Bedienung brauchbarer und lieber.

Wer diese Symbole und Icons als Hilfe ansieht oder sie einfach und schlicht gefallen: Es stehe ja jedem frei, sie zu verwenden … oder eben nicht.

Mir hilft ähnlich wenig wie ein Symbol auch nicht die Rahmen um die Programmfenster. Ich empfinde sie gar als störend: ein unnötiger zusätzlicher Input, der mir keine bessere Orientierung auf dem Monitor bietet.
Vielmehr erscheint er mir wie eine „Hürde“, über die ich ins Programm hineingehen muss, um an meine Dateien, Ordner oder Bilder zu gelangen.

Manche indessen bevorzugen filigrane, zarte Umrandungen der Fenster – andere eher einen dicken, schmucken, farblich abgesetzten Rahmen:

Auch hier gelte, jeder wie er es braucht und mag …

Mir ist also deutlich und klar, dass meine Gestaltung meiner „Arbeitsumgebung“ nicht verallgemeinerungsfähig ist, halt nicht „für alle“ richtig und gut.

Die Orientierung anhand eines Symbols oder Icons kann dem einen helfen – mich nerven diese Bildchen halt, andere wiederum benötigen sie auch nicht, als Dekoration aber gefallen sie …

Ähnlich halt wie mit den Rahmen um den Programm-Fenstern …

Jeder macht es dann so, wie er es braucht und für gut befindet …

Solange es ihm möglich bleibt …

„Design-Varianten der Titelleisten von Programmfenstern“

Jeweils mit Symbol-Button fürs „Schließen, Maximieren, Minimieren …” oder halt ohne solcher Button.

Dies alles sind Optionen. Und als solche zu bewahren.

Denn dies gibt es nicht: „Das einzige, wahre, das richtig gestaltete, das schönste designte Programmfenster.“

Wohl aber gibt es Werkzeuge, so dass (…) jeder nach seiner Façon selig werde – wie der alte Fritz mit Fug und Recht meinte. Und diese Werkzeuge gilt es zu bewahren, zu verbessern, zu stärken.

Es genügt mir definitiv nicht, bei einem eingerollten oder minimierten Fenster nur das Firefox Symbol zu sehen – es reicht mir nicht einmal die textuelle Ergänzung zum Symbol in Form des Programmnamens Mozilla Firefox – schon gar nicht Mozilla Fir: Sprache angepasst an irgendeine Symbolbreite auf einer Taskleiste …

Ähnlich verhält es sich bei einem Text-Editor oder einer IDE mit mehreren geöffneten Tabs …

Ich brauche den Namen der geöffneten Datei, respektive der geöffneten Website, den Namen des Ordners oder des Fotos.

Denn dies sind die Informationen, die ich für die Orientierung brauche – in der jeweiligen „Arbeitssitzung“ …

Ein deutliches Beispiel:

Wenn ich fünf oder mehr Tabs im Browser geöffnet habe, will ich diese Tabs nicht einheitlich mit „Mozilla Firefox“ benannt sehen – oder nur mit einem hübschen Symbol geschmückt.

Ich brauche natürlich die Namen der geöffneten Websites in diesen Tabs – und seien diese Namen oder Bezeichnungen (der sogenannte „title“) aufgrund mangelnden Platzes auch verkürzt …

GNOME-Programmfenster ignorieren diese Grundinformationen von Tabs und Titelleisten.

Denn Gnome unterscheidet nicht mehr die Funktionalität einer Fenster-Titelleiste zu dem, was das Programm an Funktionen inne hat.

Arbeite ich mit der IDE Bluefish, sind mitunter zwei Dutzend Webseiten geöffnet – da will ich nicht als Orientierung einen blauen, grinsenden Bluefish Symbol sehen … also, ich will keinen Fisch sehen …

Insbesondere im GNOME-Desktop erscheint der Wille, es Microsoft und Apple gleich zu tun: Den Nutzern die Gestaltungsmöglichkeiten der eigenen Arbeitsumgebung einzuschränken und Vorgaben durchzusetzen, wie man es selbst für doll und richtig befindet.

Diktat und Design

Es ist kein Argument, nicht einmal ein schlechtes Argument, zu sagen: „dann nutze doch eine andere Distro …“

Wenn Programme unter „Linux“ für GNOME geschrieben sind und werden, wabert das GNOME-Design genau eben durch diese „anderen Distros“ – wie neuerdings ausgerechnet bei Linux-Mint.

Das alles festzurrende Gnome-Design bestimmt über diverse Anwendungen das Cinnamon-Design von Linux-Mint.

Das Gnome-Design hebelt die Funktionalität von Fenster-Manager wie Openbox aus.

In dieser extremen Art und Weise, die jede Anpassung von Seiten des Nutzers zu verhindern sucht, ist es mir ein Novum – in der „Linux-Welt“ …

Es erscheint weniger als eine Farce denn als eine Dreistigkeit, wie ausgerechnet unter „Linux“ eine der wichtigen Distributionen – wie Debian es unbestritten ist – geradezu aggressiv derartige Design-Vorgaben über den eigenen Desktop „Gnome“ hinweg in die Welt drückt …

Auch dieser Gedanke von diesem Gnome-Design, dass Einrollen von Fenstern gleich zu streichen, man könne ja das Fenster immerhin minimieren, ist bestenfalls unüberlegt geboren … und in die Welt gekommen – oder schlicht frech, hochmütig und dreist zugleich.

Denn dieses Streichen des Einrollens von Fenstern „zugunsten“ irgendeines auf gefälligst irgendeiner „Taskleiste“ zu erfolgenden Minimierens, dies impliziert den Gedanken, dass der Nutzer ja eh so eine Leiste nutzt, nutzen will und ergo wohl gleich mehrere davon hat. Also wird „minimiert“ via Symbol mit abgebrochenem Text auf Leisten – deren Sinn und Inhalt dann via Hovern zu ermitteln seien …

Da helfen die besten und gern animierten „Vorschaubildchen“ aus diesem Herum-Hovern nichts: Dies ist ein Gängeln der Nutzer und eine Missachtung jeglicher Funktionalität …

Richte sich derlei ein, wer will … und wer diesen vermeintlichen Standard nicht gebrauchen kann, bekommt unverrückbar Optionen, derlei auch gänzlich zu entfernen – und keineswegs als „Trost“ diese ebenfalls animierte und als „Option“ missverstandene technische „Raffinesse“, sich diese „Leisten“ irgendwie „automatisiert“ via Maus-Gezappel doch ein- und ausblenden zu lassen …

Ich nutze keine Leiste. Ich brauche keine Leiste. Und ich will diese bunten Monitorbalken auf meiner Arbeitsfläche nicht!

Und nun?

Ich meide Programme, die für und von Gnome sind – auf Dauer ist dies gewiss keine Lösung!

Einmal rollend gedacht

Ich lasse meine Programmfenster weitgehend dort, wo ich sie brauche, rolle sie ein, rolle sie aus – je nach Bedarf …

Das Arbeiten mit Leisten ist mir bekannt. Im Vergleich zu der Fensteranordnung in Openbox keine Option mehr!

Auf den Monitoren ist genügend Platz für alle Programm-Fenster in der jeweiligen Sitzung, wenn man sie an der Stelle einrollen kann, wo man sie braucht – mit aussagekräftiger Beschriftung in der Titelleiste.

Wird der Platz auf einer Arbeitsfläche knapp: der Mensch hat heutzutage zwei … bei Bedarf auch vier Arbeitsflächen …

Ich minimiere Programm-Fenster selten.

Warum streicht Debian-Gnome eine hilfreiche, zweckmäßige Funktion der Programmfenster, die da Auf/Abrollen heißt?

Wozu ist derlei gut?

GNOME raubt gewiss nicht nur mir eine Arbeitsweise mit und eine Funktionalität von Programm-Fenstern nicht nur unter Openbox: via Diktat eines festgezurrten Designs „seiner“ Programmfenster, die in die Distributionen schwappen. Dies ist dreist. Dies ist frech. Dies ist mindestens gedankenlos, unüberlegt. Dies ist nicht „Linux“ …

Um es hier abzubrechen – es ließen sich noch einige Dutzend Beispiel anfügen, von Scrollbars und Arbeitsplatzverwaltung, von ermüdenden Effekten und einer Ignoranz gegenüber hilfreicher Semantik … wo Funktionalität stirbt zugunsten eines Designs, wünsche ich mir – es ist ja bald Weihnacht – das Sterben von allen Design-Kapriolen namens GNOME …

Das Gnome-Design

Das Gnome-Design nimmt folgenden Einfluss auf die Funktionalität von Programm-Fenstern:

Debian-Gnome überholt mich ungehörig von rechts – wie zuvor Windows und Macintosh … dies sind keine guten Entwicklungen in der „Linux-Welt“ …

Weiterführend, ergänzend:

Openbox, Installations- und Nutzungs-Varianten – Besonderheiten.

Openbox – hilfreiche Links.

Ein Experiment – mit Kritik an Entwicklungen im Design (Video und Text)

Openbox, ein Werkzeug, für Distributionen und Programme – Video: Button versus Titelleisten-Menü … und die Frage nach Icons (Video und Text).
Seite 2: Openbox versus Gnome (Video und Text).
Seite 3: Openbox – Symbole und Sprache – Über die Funktionen von Programmfenstern und Programme (Anwendungen). Beispiele.

Client-side decoration … und Gnome-Zentrismus.

Openbox – die Suche nach Titelleisten. Wege des Designs unter „Linux“.

Openbox versus Gnome – Symbole im Design versus textueller Menüführung; Beispiel Vollbildmodus. Wege des Designs unter „Linux“.

Openbox versus Gnome – Beispiele Funktionen Auf/Abrollen, Verschieben, Größe ändern. Wege des Designs unter „Linux“.

Openbox versus Awesome – Vergleich zweier Fenstermanager, Floating versus Tiling.

Openbox – hilfreiche Funktion „gmrun“ (Run-Funktion) – und selbst entscheiden: Titelleiste sowie Menübar ein/aus.

Openbox – Vergleich Floating / Tiling, Maus / Tastatur

Openbox – Layer: Immer im Hintergrund

Openbox – Nutzer-seitige Steuerung von Programmfenstern, Arbeitsplatzgestaltung am Computer.

Openbox – Nutzer versus Client-side decoration (CSD)