Openbox, ein Werkzeug

Kritik an Entwicklungen im Design von Distributionen und von Programmen (Anwendungen) insbesondere unter Linux.

Über das Video:

Taskleisten (Panels), Button, Symbole, Icons sowie Tooltips einschließlich Hover-Effekte sind Optionen:

Tooltips sind gar als Notlösungen zu sehen.

Das geschriebene Wort, die Erklärung einer Programm-Funktion via Sprache indessen sind Pflicht … notfalls via „Tooltip“ …

Zeige Beispiele des Designs anhand meiner Programmfenster und anhand der „Einstellungen“ des Programms Drawing im Gnome-Design.

Das gesamte Gnome-Design taugt nichts – besonders nicht als Vorbild für andere Distributionen unter Linux.
Insgesamt erzeugt das Gnome-Design keinen „modernen Eindruck“ … vielmehr weckt es Fragen über Fragen …
wohin die „Linux-Welt“ will …

Fotos aus dem Video:
Drawing, unter Linux-Mint „Zeichnung“ genannt, ein Programm für den Gnome-Desktop:

Programm für den Gnome-Desktop. Info Drawing – Gnome-Programmfenster.

Die von Gnome irreführend als „altmodisch“ bezeichnete Einstellung des Programmfensters zeigt sich tatsächlich höchst „modern“: in der zweckmäßigen Trennung von Funktionen des Programmfensters zu den Funktionen des Programms, in der Beschriftung der Programm-Funktionen, im umfangreichen Titelleistenmenü sowie in der Möglichkeit der Umsetzung zahlreicher Einstellungsoptionen mit Hilfe eines Fenstermanagers durch die Nutzer …

Was auch immer daran „altmodisch“ sei …

Gnome – Einstellungsoption „altmodisch“.

[Textfassung:]

Design und Nutzer

Kurzfassung: Leisten, Button, Symbole, Icons sowie Tooltips als Optionen.
Funktionale Gestaltung von Programmen und Distributionen – Design als Wahlmöglichkeit …

Ich wüsste keine bessere Entscheidungsinstanz als den Nutzer für die Beantwortung der Frage, welches Computer- und Programm-Design gefällt und wie man arbeiten möchte.

Programm-Symbole oder Button, deren Aufgabe es sein soll, Funktionen von Programmen zu verbildlichen, brauchen Text, mindestens in der Form eines Tooltips, um den fragenden Nutzern Programm und Funktionen erklären zu können.

Icons und Programm-Symbole sind kein Ersatz für Schrift.

Ein Symbol-Button als „Dekoration“ bliebe ja unberührt, wenn das Symbol neben einem Wort stünde, einem Wort, das die Funktionen des Programms benennt.

Schrift versteht der Mensch … Symbole, Icons, Button übersetzt der Mensch in Schrift, damit er sie versteht.

Gestaltung orientiert sich am Menschen?

Schreiben wir mutig: Design stützt Inhalte und Funktionen – zum Beispiel beim Nutzen von Programmen eines Betriebssystems.
Design stützt das geschriebene Wort.
Ein gelungenes Design hilft den Nutzern, ein Programm am Computer besser zu verstehen, um es für die zugedachte Aufgabe gut nutzen zu können.

Behaupten wir einmal: Ein Icon anstelle von Text hilft nicht – es spart bestenfalls Platz und mag im „Handy-Zeitalter“ sogar irgendwie „normal“ erscheinen. Dennoch:

Selbst der Gnome-Desktop, der irgendwie als überdimensioniertes Handy erscheint, nutzt für die mit offenbar Leidenschaft gestalteten Symbole das gesprochene respektive geschriebene Wort: unter dem Symbol stehend, mitunter gekürzt, geradewegs abgebrochen in der zugedachten Breite des Symbols bis zerstückelt erscheinend – und / oder es erscheint das Symbol, dessen Erklärung via Tooltip bemüht erfolgt.
Text aber erscheint in diesen Formen selbst auf dem Gnome-Desktop noch unersetzbar beim Symbol, beim Icon, beim Button – damit die Nutzer die Bedeutung verstehen können.

Symbole, Button benötigen insbesondere Text, wenn Symbole, Button, Icons eine Funktion inne haben: Öffnen eines Programms, Kopieren, Druck aktivieren, verschieben, minimieren, maximieren … löschen.

Bei Dutzenden von Programmen und deren Programm-Symbolen machen diese Bemühungen rund um eine „textuelle Erklärung“ des jeweiligen Symbols nicht nur Sinn, sie sind notwendig: Kein Mensch kann sich die mittlerweile unzähligen verschiedenen Symbole und deren zugedachten Bedeutungen merken.

Und kein Nutzer will ernsthaft „experimentell“ Button, Symbole bedienen …

Text und Symbol – Symbol ohne Text – Text ohne Symbol

Button, Symbole ohne textuelle Infos sind bestenfalls Schmuck – und könnten folglich auch weg …

Das geschriebene Wort ist und bleibt der Anker für den Nutzer beim Öffnen von Programmen, beim Aufrufen von Funktionen.

Sprache ist Pflicht im Design von Betriebssystemen, von Programmen.

Tooltips indessen und Icons, Symbole und designte Button gehören in die Kategorie „optional“. Denn die Sprache kommt prima ohne Hover-Fensterschen und bunten Bildchen aus – nur gewendet geht es nicht … Button ohne Sprache sind eine Zumutung.

Der Fenstermanager Openbox erlaubt es folglich und folgenlos, Icons, Button, Symbole (fast) gänzlich zu entfernen.

Leider wurde die Entwicklung dieses Fenstermanagers zu früh eingestellt.
Dennoch: Er bleibt bis dato nutzbar.

„Bis dato“ als Einschränkung, weil die Tendenzen im Design heute von Betriebssystemen unter Linux zeitigen, dass Button und Symbole vor Text und sogar anstelle von Text den Nutzern vorgesetzt werden.
Dies betrifft u.a. aber insbesondere den Gnome-Desktop.

Der Fenstermanager Openbox erlaubt es also bis dato, Icons, Button, Symbole zu entfernen.
Für mich ein Segen! Auf meinem System – ich nutze u.a. Linux-Mint, Version derzeit „Vanessa“ – sind keine Icons zu sehen, weder im Menü des Betriebsystems, nicht im Menü der Programme, weder auf irgendeiner Titelleiste, noch im Submenüs von Programm-Fenstern.

Taskleisten – und andere Parkplätze für „Icons“

Die Ablage von Symbolen auf sogenannten Leisten oder Taskleisten erübrigt sich, wenn Leisten nicht genutzt werden, wie es das Grundprogramm von Openbox anbietet:

Die Nutzung von Leisten ist eine Option.

Leisten, Button, Symbole, Icons sowie Tooltips sind unter Openbox Optionen: Man kann derlei nutzen, wenn der Nutzer derlei braucht oder mag – oder weglassen, wenn derlei stört, nervt, den Arbeits- bis Spiele-Fluss am Computer erschwert …

Hauptmenü der Linux-Mint-Distribution unter Openbox

Bild 1 – Beispiel Hauptmenü (Linux-Mint-Menü, selbstbestimmt unter Openbox): alle Programme, die ich nutze, in der Ordnung, wie ich sie brauche. Andere Programme sind auskommentiert oder erst gar nicht in mein Menü gekommen, sie sind quasi entfernt – selten benutze Programme finden ihren Platz in Submenüs … Icons, Hover-Effekte sind entfernt … wer indessen beides mag, füge derlei ein … es sind Optionen.

Openbox macht jedes Icon und jeden Tooltip … und diese jenseits vom Handy nicht sterben wollende Hover-Effekte … zu einer Option – quasi überflüssig.

Da kann der Symbol- und Effekte-Designer gestalten, was immer er will …

Das Icon in der Titelleiste eines Programms, wie die Icons innerhalb der Menüs und Menübars von Programmen, die vorgeschlagenen respektive vorgegebenen Icons des Betriebssystems, sie alle sind Optionen und mit Hilfe u.a. von Openbox entfernbar. Wunderbar!

Gestaltung orientiert sich am Menschen.

Und ja, man kann es allen recht machen!

Steht ein erklärendes Wort neben einem Icon, bleibt die Funktion erhalten, wenn man das Icon entfernt. Symbolisiert das Icon alleine eine Funktion, wird es eng für den Nutzer …

Die Design-Kapriolen trauen sich noch nicht, die Funktion „Alles unwiederbringlich löschen“ als reinen Symbol-Button anzubieten – ohne auch nur eine zweite Nachfrage in Textform.
Warum nicht?

Text und Funktions-Button gehören zusammen, wenngleich der Button weg kann, der Text indessen nicht.

Die Entwicklungen im Design – schreiben wir einschränkend – unter Linux respektive von Seiten einiger Betriebssysteme sind zu hinterfragen.

Gthumb unter Gnome ist Pix unter Linux-Mint?

Ein Beispiel ist Gthumb unter Gnome, kompiliert von Linux-Mint bis Version „Victoria“ zu Pix:

Gthumb unter Gnome arbeitet neuerdings fast ausschließlich via Icons, die via Tooltips erklärt werden und aufgrund der Vielzahl dieser Icons den Nutzern auch erklärt werden müssen, will man nicht „experimentel“ seine Fotos bearbeiten, indem der Mensch diese Icons „probeweise“ durchklickt im Bemühen, sich die Bedeutung dieser Symbole dann für die nächste Runde zu merken.

Diese Button-Symbole haben Text nur noch als Tooltip – und beide können nicht entfernt werden zugunsten des geschriebenen Wortes.

Statt aussagekräftige Menübar und Menüs: bunte, designte Bildchen fürs „Hovern“, um bunte, designte „Tooltips“ zu sehen – die den Text liefern.

Diese Art der „Modernisierung“ lässt mich an kleine Kinder denken, die noch nicht schreiben können, Bilder aber können sie malen …

Pix indessen war und ist Gthumb – aber in der Menüführung mit Text, wenigstens bis Version „Victoria“.

Gthumb kompiliert von Linux-Mint zu Pix.
Ab Version „Victoria“ wird das textuelle Pix zu einer vom Gnome-Designern festgezurrten Ansammlung von Symbol-Buttons und deren Tooltips.

Diese Entwicklung(en) des Gnome-Designs schluckt auch die von Openbox beeinflussbare Titelleiste der Programme: Die Titelleiste existiert bei Gnome de facto nicht mehr. Programmfenster können nicht mehr eingerollt, sondern alleine noch minimiert werden, textuelle Informationen auf der Titelleiste sind reduziert, de facto entfernt.

Hier nimmt Design Einfluss auf die Funktionalität.

Da Debian Grundlage für zahlreiche weitere Distributionen ist, sind die Einflüsse des Gnome-Design auf solche sogenannten Forks erheblich: Programme werden „für Gnome“ geschrieben und entwickelt.

Ein Programm duckt sich unter dem Vorgabe-Design einer der wichtigen Distribution unter Linux – und verändert nicht nur Gnome.

Text, der zweckmäßig einst auch in Gthumb neben Icons und Symbolen stand und Optionen der Nutzer-seitigen Gestaltung der Titelleiste nicht einschränkte oder gar verhinderte, übernimmt und bedient dieses „sprachlose“ Gnome-Design.

Dies nennt man nicht Modernisierung, sondern Rückschritt.

Ab Version „Victoria“ übernimmt auch (ausgerechnet) Linux-Mint dieses Gthumb-Design: Design-Vorgaben im Namen von Gnome.

Beispiel eines zweckmäßigen Menüs unter Pix vor der Version „Victoria“ bei Linux-Mint:

Programmmenü Pix: Symbole UND Text

Bild 2 – Pix-Programm bis Version „Victoria“: rechte Spalte, beschriftete Funktionen, meinetwegen mit Icons. Diese Icons „übersehe“ ich, denn es bedarf nicht deren Interpretaion, um die Funktionen zu verstehen … Titelleiste, Menübar samt Menüs sind verfügbar …

In dieser Ausführung von Gthumb respektive Pix entfällt dieses Hovern über irgendwelche Symbole zwecks Abfrage erklärender, textueller Tooltips – Hovern ist und bleibt eine Option, eine Notlösung, zumal im Zeitalter des Handys und Co., wo Hovern und Tooltips unbekannt, ja nutzlos sind …
Abkürzungen, Akronyme und derlei gehören (mindestens ein Mal) ausgeschrieben, also via Text erklärt: „Symbole“, „Hovern“ und „Tooltips“ helfen hier nicht.

Wenn Handyformate als Designvorlage herhalten sollen, dann in solchen Hinsichten: Schreibt Text, Designer dieser Welt.

Funktionen und Bedeutungen müssen in Textform verfügbar sein – darüber täusche mal auch nicht der Einsatz des „Hamburger Menüs“, das so langsam den Desktop erobern will, um vermeintlich all überall „Standard“ zu werden.

Die neuzeitlichen Entwicklungen, Text zu streichen, ihn geradewegs zu meiden und anstelle dessen Symbole zu verwenden – im Stil eines Handy-(Web-)Design als „moderne“ Kommunikationsform – ist wider dem Geist jeglichen Designs, das den Nutzern insbesondere eines Betriebssystems über dessen Programm- und Funktionen-Vielfalt informieren will.

„Gnome-Design“ ist bald ein Synonym für inkonsistentes Design … obgleich das Gegenteilige behauptet wird.

Titelleisten-Menü und Symbol-Button
Titelleisten-Menü ohne Symbol-Button

Unter meinen Einstellungen unter Openbox sehe ich überall Text, keine Button-Symbole, ich vermisse diese Bildchen nicht.
Gewendet indessen würde ich den Text arg vermissen, sähe ich nur noch Symbole …

Button-Symbole sind wie Icons pure Dekoration … bestenfalls eine augenfällige Orientierungshilfe … für den Nutzer aber entbehrlich. Allesamt. Wenigstens entbehrlich, soweit es die Bedienung von Betriebssystem und Programmen betrifft.

Das via Rechtsklick der Maus (oder in Variante via der Tastatur) derzeit noch aufrufbare Titelleisten-Menü ist auch dann verfügbar, wenn irgendwelche Buttons auf der Titelleiste herumgeistern, deren Funktionen via schon erwähnten, nicht müde werdenden „Tooltip“ ihre Erklärung finden.

Dieses Titelleistenmenü zeigte bis dato stets dieselben Funktionen – bis Gnome es anders entschied, Funktionen ersatzlos strich: das Auf/Abrollen, das Verschieben von Programmen auf Arbeitsflächen.

Dieses Titelleisten-Menü ist in der Regel im Funktionsumfang umfangreicher, universell für alle Programmfenster, effizienter als es jede Button-Sammlung je sein wird.
Titelleistenmenüs sind stets ausreichend gut beschriftet, leichter zu bedienen – und selbst im Seitenbereich der Programmfenster aufrufbar, wenn das „Padding“ denn stimmt – was unter Openbox problemlos von Seiten der Nutzer anpassbar ist.

Der universelle Charakter des Titelleistenmenüs gibt Struktur und Orientierung – was Gnome da anbietet, macht diese Funktionen oder Eigenschaften des Titelleistenmenüs nicht besser, sondern zeitigt einen Rückschritt.

Was schlechter ist, sollte das Gute nicht ersetzen.

Auch jene Anpassbarkeit der funktional zu denkenden Rahmenbreite ist eine Eigenschaft der Programmfenster, die unabhängig vom Betriebssystem und Design zu bewahren ist.

Programm-Fenster-Menü von Fensterseite aufgerufen

Bild 3 – Aufruf des „Titelleisten-Menüs“ am Fensterrand – Openbox erlaubt eine beliebige Breite des Fensterrahmen zwecks Ändern der Fenstergröße und eben auch eines bequemen Aufrufen des Menüs: Wer es mag, fügt bunte Icons hinzu …

Button auf Titelleisten samt Hover-Tooltip indessen sind optional, auch wenn daraus gern ein Fetisch gemacht wird und sich die Design-Kapriolen rund um Buttons und Icons gegenseitig überschlagen …

Dass Desktop-Designer diese Symbol-Button und deren Tooltips weiterhin als „Standard“ pflegen und vorantreiben, ist ein Armutszeugnis des Nachdenkens über Aufgaben und Ziele von Design.

Anstatt zu bewahren, was gut ist und daran anzuknüpfen, „Modernisierungen“ in irgendeine Richtung, wie etwa das Streichen von Text zugunsten eines „Hamburger Menüs“, einer Menüführung des Handy-(Web-)Designs, welches zunehmend die Desktops erobert … und am Ende alles „sprachlos“ zurücklässt.
Ich warte schon auf die erste E-Mail, die ihren Inhalt hinter drei waagerechten Strichen verbirgt … und im Button-Style endet: VG … LG … MfG …

Symbol-Button versus Titelleisten-Menü

Charakteristika Button:

Charakteristika Titelleisten-Menü:

Scroll-Leisten – Animationen von Werkzeugen

Dass so mancher Designer-Wille nur noch Kapriolen schlägt, zeigt auch die Entwicklung der Scroll-Leisten:

Deren „modernes“, sprich animiertes, penetrantes Erscheinen und Ausblenden, sobald die Maus im Arbeitsbereich unterwegs ist (und etwa bemüht einen Text verfassen oder lesen will) ist wie ein Hammer in der Werkstatt, den der Mensch just NICHT braucht, weil er mit der Säge arbeitet. Ein Hammer aber, der sich unbeirrt ständig via Blinken und Rufen anbiedert, sobald der Mensch die Säge, die Feile … bewegt, also am Werkstück (sprich Text oder Bild) arbeitet.

Das penetrante Sich-Anbiedern von Werkzeugen ist ein Graus.

Wenn dieser Hammer dann auch noch seine Farbe ändert, sobald man ihn dann doch nutzt, es ist so überflüssig, wie es bei der Scroll-Leiste und dem Slider überflüssig ist – und nach Dutzenden Anwendungen verkommt dieses „dolle Design“ auch nur noch zu einem nervenden, jegliche Arbeit störendem Geblinke und Gezappel.

Warum wird es dem Menschen mit solcherart „Über-Design“ zunehmend schwer gemacht, sich konzentriert auf seine Arbeitsumgebung bewegen zu können?

Auch diese fummelige „Breite“ des Slider – wohl gedacht für den jugendlichen Feinmotoriker? – dient nicht seiner Grundfunktion: Dem Nutzer es zu ermöglichen, sich rasch Inhalte zu erschließen …

Scrollbars sind wie Programme Werkzeuge – die sollten nutzbar sein und vorrangig, ja ausschließlich dahingehend designt werden.

Ein animiertes Blinken, unaufgefordertes Erscheinen und Verschwinden, ein Sich-Verformen … ein mit blanken Symbolen überfrachtetes, „sprachloses“ Design eines Programms gehört nicht dazu, auch nur irgendeinen Nutzen zu fördern.

Mit so etwas mag man sechsjährige Computer-Lümmel und Liselotten beeindrucken …

Beispiele Scrollbar und Slider

Varianten im Design …

Etwas versteckt in einem Detail-Tag:

Werkzeuge auf der Werkbank …

Wenn Design Arbeitsumgebungen beschwert

Pix ist leider ab der Linux-Mint-Version „Victoria“ wie Gthumb unter Gnome:

Die Orientierung und Struktur gebende Titelleiste des Programmfensters wurde umfunktioniert zu einer von vielen Bedienflächen eines Programms, wohl entstanden an irgendeiner nackten Konsole irgendeines Nerds, der den Rest der Menschheit via seinen Design-Spielereien mit dem quälen will, was er selbst im „produktiven System“ nicht nutzt.

Button und Symbole des Programms „Pix“ sind bei Linux-Mint wieder ohne Text, wie dieses aktuelle „Gthumb“ unter Gnome.

Was für ein Rückschritt in der Design-Entwicklung …

Tooltip-Text wird dann obligatorisch in dieser Button-Wüste, somit wird auch der Linux-Mint-Nutzer gegängelt, „Herum-Hovern“ zu müssen.
Gestaltungsoptionen werden verhindert: bald chancenlos für den Nutzer, es für sich gut anzupassen, etwa via Openbox oder einer eigenen CSS-Datei, was bei Pix zuvor problemlos möglich war.

Openbox kapituliert neuerdings vor den Design-Ambitionen von Programmen wie unter Gnome.

Und obgleich sich Linux-Mint nicht zuletzt wegen diversen, hier nicht zu wiederholenden Design-Streitigkeiten von Debian verabschiedete, springt Linux-Mint ab Version „Victoria“ nun via Anpassung von Pix an Gthumb-Gnome genau dort wieder zurück: Festgezurrtes, hochmütiges, ja geradezu dümmliches Programm-Design, das sich vermeintlich „intuitiv“ (Zitat Mint) via Button-Häufungen samt Tooltips allen Nutzern wohl noch irgendwie erschließen wird.

Keine Verbesserung der Nutzbarkeit also, sondern Design-Klötze, die den Nutzer vor die Nase gesetzt werden … Microsoft und Apple lassen grüßen.

Die Stärke von Linux war und ist, Vielfalt anzubieten – Wahlmöglichkeiten, in vielerlei Hinsichten.

Solche Design-Entwicklungen indessen sind wider diesem Geist von Linux.
Sie sind wider dem Geist jeglichen Designs.

Das Menüs und Menübars aus Programmen wie Pix (Taschenrechner-Gnome, ja sogar von Firefox) verschwinden und stattdessen schier unveränderliche „Symbol-Leisten“ angeboten werden, ist eine mehr als ärgerliche Entwicklung im Computer-Design unter Linux.

Ein zweckmäßiges, hilfreiches, verstehbares, bedienbares Menü:

Text statt Icons

Bild 4 – Beispiel eines zweckmäßigen Menüs respektive einer Menübar anhand von Pix vor Version „Victoria“. Dieses textuelle Design prägte auch die älteren Versionen von Gthumb. Ich habe die Menü-Icons entfernt – mich stören sie, wem es gefällt, lässt sie … oder ersetzt sie durch andere … sie sind allesamt optional.

Seit wann orientiert sich denn „Linux“ an vermeintliche Standard-Vorgaben von Mircosoft und Apple?

Was da reitet in den neusten Design-Entwicklungen unter Linux, es hat nichts mit irgendeinem „Windows (Nutzer)” zu tun, dem man sich anbiedern will, vielmehr erscheint es als Kind eines mangelhaften Nachdenkens und Umsetzens von Grundsätzen des Designs, das Funktionen und den Menschen als Orientierung haben sollte.

Dabei könnte Linux am Desktop hier Vorreiter werden! Und den beiden Protagonisten „Microsoft und Apple“ zeigen, wo der Hammer (samt Säge) in der Designer-Welt hängt!

Eine Weiterentwicklung von Openbox oder eine Neuauflage – auch unter Wayland – wäre ein Segen.

Denn derzeit hat Openbox noch relative Kraft genug, dummes Zeugs von Designern wegzuwischen und Betriebssystem samt Programme nutzbar zu halten oder wieder nutzbar zu machen …

Aussichten …

Wäre ich kein Rosenbauer, sondern Entwickler mit ausreichend Kenntnissen in diversen Programmiersprachen, es wäre für mich die denkbar reizvollste Aufgabe, ein solches universell einsetzbares „Design-Programm“ zu entwickeln, wie es Openbox in seinen Anfängen zeitigte … es würde mir Spaß bereiten, im Dienst der Nutzer von Betriebssystemen und Programmen weltweit unterwegs zu sein … soweit es mindestens „Linux“ betrifft. Es wäre mir ein Genuss, mir diesen Brocken aufzuhalsen, ein Programm anzubieten, das etwa alle Gnome-Designer-Träume von der eigenen Arbeitsumgebung gnadenlos wegwischt …

Es bleibt mir leider nur der Appell solcher Texte … mein bemühtes Erlernen von Programmiersprachen … und die Hoffnung in die Zukunft eines Nutzer von „Linux“, nicht in den Design-Vorgaben irgendwelcher „Standard-Nerds” zu enden, Nerds, die auf ihren Konsolen mit der Gestaltung von Werkzeugen und Arbeitsumgebungen herumspielen im Glauben, den Nutzern zu dienen …

Wege zu „Linux“

– beispielsweise über Macintosh …

Etwas versteckt in einem Detail-Tag:

Ein Programm für die Bild-Bearbeitung unter Macintosh

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 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)