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.
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
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).
Durch das Hinzufügen von wenigen Design-Elementen
ist dieses Grundtheme rasch „aufgewertet“ und anpassbar
– einzelne im Video gezeigte Schritte:
/[*] Hintergrundfarben */
- Hintergrundfarbe im Titel-Bereich hinzufügen / ändern,
- die Hintergrundfarbe des Titels als Orientierung nehmen für die Farben-Auswahl in den Menüs:
Hauptmenü, Arbeitsplatz-Menü, Titel-Menü
/[*] Rahmen, Hervorhebung */
- Hervorhebung offener / aktiver Dateien im notebook, hier exemplarisch durch Unterstrich (border-bottom)
- dieser Unterstrich als Orientierung für:
Rahmen (border) für Fenster-Menüs in menubar, Tooltips, weitere Menüs des Fensters
– dies schafft schlichte Konsistenz im Design und trägt zur Funktionalität bei - Rahmen um die gesamten Programmfenster gestalten
– Farbe und Rahmenstärke orientiert an 3) und 4) - Icons einfügen in
- - Titelleisten (Datei rc.xml)
- - Arbeitsplatz-Menü (Datei rc.xml)
- - Hauptmenü (Datei menu.xml, Pfade von Icons angeben)
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:
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.
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.
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 …
##### 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.
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 …
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.
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.
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.
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.
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:
- Schrift serif, Schriftgröße
- Anmeldefenster dezentral versetzt
- Hintergrundfarbe #fff (weiss)
Weitere optionale Anpassungen:
- Pfad-Angabe zu einem Foto für den Hintergrund
- Standard-Icon (links der Eingaben „Name / Passwort“) kann via Pfad-Angabe durch eigenes Icon / Foto ersetzt werden
- Änderung der Darstellung der Uhr
- und vieles mehr …
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).