Openbox, ein Grund-Theme in weiß

Kritik an Entwicklungen im Design von Arbeitsumgebungen am Computer und von Programmen (Anwendungen).

Dieses Video ist eine Art Anhang einer Reihe von vier Videos:

Weiterführend:

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 von Programmen (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)

Inhalt des Videos in kurzer Textfassung

Tabula rasa = Grundtheme weiss = ein Experiment

Ein Grundtheme: als Ausgangspunkt für eigene Anpassungen an Design und Funktionalität.

Beispiel: Übersicht in den Programm-Fenstern nicht durch vorgegebene Button und Hover-Effekte, sondern durch eigene Abstände (margin, padding) und Gestaltung der Schrift (Größe, Art, Farbe).

Button und Hover-Effekte als Option – nicht als „Standard“ des Designs.

Durch das Hinzufügen von wenigen Design-Elementen ist dieses Grundtheme rasch „aufgewertet“ und anpassbar
einzelne im Video gezeigte Schritte:

/[*] Hintergrundfarben */

Die Anpassbarkeit von Farben gehört zur Grundpflicht eines Designs,
wie die Anpassbarkeit von Schriftart und Schriftgröße …

/[*] Rahmen, Hervorhebung */

Icons sind kein Ersatz für Schrift. Icons sind optional zu sehen. Wer sie nicht nutzt und auch in deren Design keinen Wert sieht, sollte die Möglichkeit bekommen, sie zu entfernen.

Beispiel zeigt, dass mit wenigen Änderungen für den Nutzer viel erreicht werden kann hinsichtlich Anpassung von Design und Funktionalität.

########## PERSPEKTIVEN

Wünschenswert wäre es, es dem Nutzer GRUNDSÄTZLICH zu überlassen, solche Anpassungen vornehmen zu können:

Grundtheme installieren + Handreiche eines „Fenstermanagers“ in der Art von Openbox.

Openbox aber in der Erweiterung, auch Scrollbar, Menubars, Notebooks, Tooltips und demnach Hover-Effekte, allgemeine Abstände, Schriften, Monitorbereiche usw. weitestgehend anpassen zu können.
Handreiche: grafische Tool(s) und / oder ein solides Handbuch für die Bearbeitung der relevanten Dateien.

Installation einer ISO mit „Out-Of-The-Box“-Umgebung:

Wem diese „Out-Of-The-Box“-Umgebung gefällt und der Nutzer damit klar kommt, dann ist ja alles gut.

Wer aber Änderungen wünscht oder gar benötigt, sollte auf ein Grundtheme zurückgreifen können, das (gefahrlos systemeigen) angepasst werden kann (Arbeitsumgebung in Konsequenz „personalisieren“) …

Entfernbarkeit von Icons und Tooltips

Zu Icons, siehe zuvor – Icons sind als Option zu werten.

Tooltips erklären in Sprache verfasst in der Regel Symbole.

Spätestens nach der hundertsten Öffnung des Firefox über das Symbol des Erdball-Fuchses, benötigt kein Mensch einen Tooltip, der einem erklärt, dass Firefox ein Browser für den Internetzugang ist.

Firefox – Ihr Zugang ins Internet – immer wieder und wieder und wieder …

Dasselbe mag der Mensch für Button mit der Funktion „schließen“ denken …

Einblendungen in der Statusleiste

Die Einblendungen indessen in der Statusleiste von Programm-Fenstern machen es vor:

Hovern über einen Bereich zeigt IM FUSS des Fensters eine dezente Erklärung des Symbols, des Button, des Reiters … in vernünftiger Sprache verfasst.

Auch in sog. Whiskey-Menüs ist dies zu finden …

Anstelle von aufpoppenden, zum Teil überblendenden (also störenden), penetranten Tooltips mit mitunter NULL-Informations-Wert, wären diese Verschiebung in den Fuß-Bereich nicht nur hilfreich und gut, vielmehr mit der Funktion zu verknüpfen, auch diese Informationsabgabe in der Statusleiste via einfachen Klick (meinetwegen auf ein vorangestelltes Symbol) AN respektive AUSSTELLEN zu können

„Tooltips: An | Aus“

Tooltips gehören in die Kategorie „optional“.

##### Wünschenwert wäre ferner

Eine Vereinheitlichung der Design-Sprachen (Gtk, Qt, CSS …).
Leitend unter dem Deckmantel der relevanten Cascaing Style Sheets (CSS), die auch in der Webgestaltung grundlegend sind und als eine Auszeichnungssprache den Grundsatz pflegen, „Inhalt und Design“ strikt zu trennen.

Diese zweckmäßige Trennung von Inhalt und Design betrifft auch die zweckmäßige Trennung von „Funktionalität und Design“:
Design steht bei den Programmen (= Anwendungen für bestimmte Aufgaben am Computer) im Dienst der Funktion – nicht umgekehrt.

Inhalt – Design

Funktion – Design

Es ist und bleibt eine Unsitte, Elemente der Semantik zu Design-Elementen zu degradieren.
„Fettschrift“ ist eine Sprachauszeichnung – kein gefälliges Instrument, um kenntlich zu machen, dass eine schnöde Datei bloß und schlicht geöffnet ist … in dieser „Design-Konsistenz“ sodann auch Fettschrift für die Kennzeichnung eines neuen, noch leeren Dokuments herhalten muss: vorauseilende Fettschrift für Nichts …

Sagen wir es bei der Betrachtung eines Betriebssystems so: Derlei ist unprofessionell.

Werkzeuge

Scrollbars sind ein Hilfsmittel, ein Werkzeug, um sich den Inhalt eines Fensters gut zugänglich zu machen – es ist kein Element des Designs, das sich in Farbe und Gestalt fortlaufend zu animieren hätte, sich ständig verstecken müsste – um aber zugleich bei jeder arbeitenden Mausbewegung im Textfeld ungefragt zu „blinken“, regelrecht einem Sich-Anbiedern gleich, und am Ende von einem unaufhörlich an der Konsole spielendem Nerd in einer derart designten „Schlankheit“ daherkommt, dass dieses Hilfsmittel gänzlich zu einer animierten Fummelbar verkommt, auf die die Maus – nun selbst wie ein Jäger – zielen und treffsicher landen muss, weil der Mensch hinter dieser Maus dieses funktional zu denkendes Werkzeug eines jeden verdammten Programmfensters nutzen will.

In diesen Design-Verirrungen ist der Nutzer nicht mehr das Maß der Dinge …

Eine Anpassung von Openbox unter Wayland?

Es wäre wünschenswert, über einen erweiterten Fenster-, Menü-Manager unter Wayland verfügen zu können – quasi ein Openbox-Fenstermanager unter Wayland mit größeren Funktionsumfang.

Eine Art „Openbox-Arbeitsumgebungs-Manager“.

Inkompatibilitäten auflösen

Die Inkompatibilität etwa von Gtk und Qt ist oft ein Graus: allgemein hinsichtlich Design und Funktionalität der Anwendungen – nicht nur hinsichtlich einer gewissen mangelhaften Konsistenz von Farben, vielmehr hinsichtlich von Funktionalitäten wie Schriftgrößen und Scrollbars …

Eine Vereinheitlichung der Design-Sprachen im Dienste individueller Anpassungen wäre ein Gewinn und eine zweckdienliche Zielsetzung, die, wie ich meine, auch den Geist von „Linux“ trifft.
In der Entwicklung sollte diese Zielsetzung mehr Konsequenz erhalten.[*]

[*] Diese Konsequenz einer am Nutzer orientierten Design-Sprache würde auch Fehlentwicklungen – wie Programme unter Gnome – entgegensteuern; Gnome erhöht die Inkompatibilität von Programmen zu anderen Umgebungen, was eine Fehlentwicklung unter Linux ist.

Vorbildliche userChrome.css – Firefox, Thunderbird

Vorbildlich ist es, eine userChrome.css schreiben zu können in der Hinsicht, dass dem Nutzer die Möglichkeit offen bleibt, via einer eigenen Datei beide Anwendungen an eigene Bedürfnisse rund um Design und Funktionalität anpassen zu können.

Nachteilig ist leider an dieser Option, es ist kein „Standard“, wenig bekannt, die Lernkurve ist recht hoch und der Aufwand auch der Wartung – etwa nach Updates – nicht gerade gering.

Ferner greifen die im Dateimanager für diese beiden Anwendungen platzierten Dateien nicht für die anderen Programme der eigenen Arbeitsumgebung.

Die vorgestellte gtk.css [Video 4] ersetzt im Kern die userChrome.css, denn sie greift auch für Firefox und Thunderbird als auch für die meisten Programme. Wo diese CSS-Anweisungen nicht greifen, sind die im Video genannten grundsätzlichen Ausnahmen, deren CSS-Ignoranz rückführbar ist auf das babylonische Kauderwelsch der Design-Sprachen.

Ich muss aber und also zu dieser gtk.css hinzufügen: Sie greift weitestgehend bei mir. Dass CSS Standard ist, ist nicht zu selten holde Theorie …

Wäre es nicht wünschenswert, dass es dem Nutzer als Standard ermöglicht wird, seinen Arbeitsplatz in jeglicher Hinsicht „personalisieren“ zu können, Systeme und Programme übergreifend – ohne gleich ins Studium des Web-Designs zu müssen?

Es fehlt hierfür allerdings nicht nur an den passenden Instrumenten („Tools“), vielmehr an einem konsequenten Willen, den Nutzer in den Mittelpunkt des Designs und der Funktionalität von Anwendungen und „Desktops“ zu stellen.

Dass proprietäre Marktgenossen, im Namen Mac und Windows, Design und Funktionen von hauseigenen Programmen zugleich als Mittel missbrauchen, Nutzer an firmeneigene Produkte zu binden, ist nicht unbekannt – aber unter „Linux“?[*]

[*] Geschäftsstrategie der „Vorinstallation“: Hardware schlicht annektiert … Programme der Textbearbeitung mit (inkompatiblen) firmeneigenen Dateiendungen, die schlicht – gepaart mit hohen Marktanteilen als hauseigene Firmenstrategie – Nutzer knebeln; Bildbearbeitungsprogramme, die meine Fotos derart ins Programm fest genietet katalogisieren, dass ein Umzug auf ein anderes Betriebssystem kaum möglich ist oder „drei Mal“ überlegt werden muss … mangelhafte Unterstützung von CSS-Standards, zugunsten der Implementierung von „betriebseigenen Standards“ … diese unsägliche Ausnutzung hoher Marktanteile und diese unsäglichen „kritischen Verbraucher“, die bequem geworden mitgehen … firmeneigene Lizenzierungen, Patentierungen von Entwicklungen, deren Substanzen von Open Source und Freier Software stammen … und am Ende diese gruseligen Versuche, diese schlappen Prozente der Linux-Nutzer am Desktop auch noch durch Firmenaggression zu gängeln …

Dieselben Akteure finden sich auch in der Entwicklung des Web.

Ein Sich-Arrangieren mit dem, was angeboten wird, ist weder von Seiten des Anbieters, noch von Seiten des Nutzers eine gute Lösung …

##### Design und Funktionalität sowie Entwicklung von Programmen, Arbeitsumgebungen

Anstatt Design und Funktionalität von Anwendungen / Desktop-Umgebungen „aus einer Hand“ zu entwickeln, könnten Ressourcen (Manpower) auf die Funktionalität fokussieren – und Fragen des Designs sorglos den Nutzern überlassen.

Ich wüsste keine bessere Instanz für die Entscheidung, was gefällt und wie man arbeiten möchte, als den Nutzer.

Obgleich gleichsam ungezählte Anwendungen unter Linux verfügbar sind, sind zu viele schlicht: „schlechte Dublikate“ allein für diverse Umgebungen – und zum Teil einfach nicht nutzbar unter der jeweiligen eigenen Umgebung: Gnome-Programme sind exemplarisch unter Openbox nicht effizient nutzbar.[*]

[*] [Beispiel: Gthumb unter Gnome – kompiliert von Linux Mint zu „Pix“; Pix ist im Design, in der Anpassbarkeit und Funktionalität das, was das durch Symbole überlastete, im Design gänzlich erstarrte Gthumb gerne wäre: eine nutzbare, hilfreiche, eine anpassbare Anwendung unter „Linux“ …]

########## ANHANG

Vergleiche ein solches Grundtheme zu den Einstellmöglichkeiten von Vorgabethemes wie „HightContrast“.

Zum gezeigten Anmeldemanager – lightdm

Zahlreiche Anpassungen sind beim Anmeldemanager lightdm möglich,
sichtbare Anpassungen bei mir:

Weitere optionale Anpassungen:

Siehe dazu lightdm-greeter, Pfad zur Datei: /usr/share/lightdm/lightdm-greeter.

Siehe für Hintergrund den zu erstellenden Ordner (lightdm-bg), Pfad: /home/horst (also IHR Name)/lightdm-bg/ihr-lightdm-hintergrund (Farbe oder Foto).