Openbox versus Gnome
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.
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
- Rahmen, er mag den eingenommenen Raum des Programmfensters auf dem Monitor besser zeigen (optional).
- Symbol des geöffneten Programms, aus einer gewissen Konvention da und dann links in der Titelleiste stehend (optional).
- Name des Programms (zweckmäßig), ggf. Versionsnummer (optional).
Beispiele: „Mozilla Firefox“, „Bluefish 2.2.12“, „Osmo 0.4.4“
Beispiel: „index.html (/home/horst/index.html) – Bluefish 2.2.12“ [Datei + Pfad + Programm] (bald obligatorisch) - Nennung der geöffneten Datei oder des Ordners (bald obligatorisch).
Beispiele: „schönstes-foto.jpg“, „wichtiger-text.odt“, „rechnung-mueller.pdf“, „rosen-seite.html“
„drohnen-fotos-juni-2023 – /home/horst/foto-kiste-2023/drohnen-fotos-juni-2023“ [Angabe: Ordner und Pfad] (bald obligatorisch). - Menü der Programmfenster: enthält Funktionen, wie der Nutzer das Programm-Fenster handhaben kann: Verschieben auf Arbeitsflächen, Präsenz in Bezug auf andere Programm-Fenster, Minimieren, Maximieren, Auf- Einrollen, Schließen.
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:
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 …
„Design-Varianten der Titelleisten von Programmfenstern“
- Nur Text.
- Text und Programm-Symbol.
- Text und Rahmen.
- Text, Programm-Symbol und Rahmen.
Jeweils mit Symbol-Button fürs „Schließen, Maximieren, Minimieren …” oder halt ohne solcher Button.
Es genügt mir definitiv nicht, bei einem eingerollten oder minimierten Fenster nur das 
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 …
Arbeite ich mit der IDE Bluefish, sind mitunter zwei Dutzend Webseiten geöffnet – da will ich nicht als Orientierung einen blauen, grinsenden 
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 …“
Das alles festzurrende Gnome-Design bestimmt über diverse Anwendungen das Cinnamon-Design von Linux-Mint.
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.
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 …
Weiterführend, ergänzend:
Openbox, Installations- und Nutzungs-Varianten – Besonderheiten.
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.