Diskussion:Openbox
Abschnitt hinzufügenMeldungen bei der Installation von Openbox[Quelltext bearbeiten]
Es gab folgende Meldung:
The following additional packages will be installed:
libobrender32v5 libobt2v5
Vorgeschlagene Pakete:
libxml2-dev tint2 openbox-menu openbox-gnome-session openbox-kde-session
Empfohlene Pakete:
python-xdg | obsession
Die folgenden NEUEN Pakete werden installiert:
libobrender32v5 libobt2v5 obconf openbox
0 aktualisiert, 4 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Sollten diese Pakete auch im Artikel erwähnt werden? --Peter Littmann (Diskussion) 22:43, 30. Mai 2019 (CEST)
- Die lib... bestimmt nicht, das würde zu weit führen. "Vorgeschlagene Pakete" sind ja schon drin, "Empfohlene Pakete" bin ich unentschlossen, bläht den Artikel vielleicht zu sehr auf, aber warum nicht? --Gosian (Diskussion) 00:11, 31. Mai 2019 (CEST)
[Quelltext bearbeiten]
Gibt es irgendeine Erklärung dafür, dass die Datei nicht mit direktem Pfad angegeben werden darf? Kann das mit einem Schreibschutz zu tun haben? Muss die Datei lxde-applications.menu so heissen, auch wenn kein LXDE installiert ist? --Peter Littmann (Diskussion) 06:10, 5. Jun. 2019 (CEST)
- Das mit dem Pfad ist so: innerhalb des Programms wird in einer Routine getestet, ob die Datei vorhanden ist. Dazu wird der Routine der Dateiname übergeben und innerhalb mit einem Pfad verknüpft, der in XDG_CONFIG_DIRS definiert sein kann. Als Beispiel: XDG_CONFIG_DIRS=/etc/xdg und die als Option übergebene Datei heisst lxde-applications.menu. Dann werden beide zusammengefügt (etwas vereinfacht gesagt) und noch "menus/" dazwischengeschoben. Ergebnis: resultierender Dateiname "/etc/xdg/menus/lxde-applications.menu" -> alles in Ordnung. Gibt man aber den vollen Dateinamen mit Pfad an, also /etc/xdg/menus/lxde-applications.menu ergibt sich nach der Zusammenfügung das hier: /etc/xdg/menus/etc/xdg/menus/lxde-applications.menu -> der Pfad kommt doppelt vor, sehr blöd.
- Ich hoffe, ich habe mich verständlich ausgedrückt. Jetzt könnte man denken, wenn XDG_CONFIG_DIRS= ist, also leer, müsste es mit dem vollen Pfad funktionieren. Ist aber nicht so, weil dann innerhalb der Testfunktion XDG_CONFIG_DIRS mit dem Default /etc/xdg belegt wird.
- Das mit XDG_CONFIG_DIRS müsste noch ergänzt werden. Also nicht diese obige Erklärung (geht IMHO zu weit), sondern weil man mit XDG_CONFIG_DIRS auch eigene Pfade für seine Menus setzen kann. Kommentar von openbox-menu:
- NOTES
* User custom menu file can be used if XDG_CONFIG_DIRS is set, i.g * 'export XDG_CONFIG_DIRS="$HOME/.config/:/etc/xdg/" to use * menu file located in $HOME/menus or /etc/xdg/ directories.
- die Datei lxde-applications.menu muss nicht so heissen, der Name ist egal, nur die Extension muss .menu sein. Aber unter MX existieren im Verzeichnis /etc/xdg/menus/ nur zwei Dateien, lxde-applications.menu und xfce-applications.menu. xfce-applications.menu funktioniert nicht (noch keine Ahnung warum), also bleibt ohne Bastelei nur lxde-applications.menu. Man kann aber eine eigene Schema- oder Vorlagen-Datei zusammenstellen und sie z.B. my_menu.menu nennen. --Gosian (Diskussion) 21:40, 5. Jun. 2019 (CEST)
Welche Zusatzprogramme passen zu Openbox?[Quelltext bearbeiten]
Könntest Du vielleicht in einem extra Abschnitt Stellung zu dazu passenden Zusatzprogrammen nehmen? Tint2 und Nitrogen hattest Du ja schon erwähnt, aber was ist mit Conky, PCManFileManager und Pidgin wie sie auf dem Screenshot dargestellt werden? Fallen Dir vielleicht noch andere ein? --Peter Littmann (Diskussion) 08:16, 5. Jun. 2019 (CEST)
- Ach, mit Empfehlungen halte ich mich gern zurück. Erstens hat da jeder seine eigenen Vorstellungen und zweitens, wo soll man da anfangen und vor allem wo aufhören? Conky und PCManFileManager (auch den Midnight-Commander) benutze ich selbst, es geht auch Thunar, Pidgin sicher auch (benutze ich nicht). Wahrscheinlich geht alles, nur macht alles Sinn? Wenn ich einen Filemanager installiere, der eine Menge Gnome- oder KDE-Pakete als Abhängigkeit nach sich zieht, so macht das in meinen Augen wenig Sinn. Also höchstens die etwas nebelhafte Erklärung "alles geht, was von so wenig anderen Paketen wie möglich abhängt". Wer unbedingt Nautilus haben möchte, kann das sicher machen, aber wahrscheinlich wird er sich bestenfalls für openbox-gnome-session entscheiden oder noch wahrscheinlicher gleich Gnome nehmen. --Gosian (Diskussion) 22:01, 5. Jun. 2019 (CEST)
- Also nach dem Motto:Less is more. ;-) Ich hatte erstmal mit Xeyes und Xclock angefangen. MC mit GUI? Ich benutze den eigentlich nur im Terminal. Bei der Sinnfrage hast Du sicherlich Recht aber woher weiss ich und die anderen Benutzer welche Pakete zuviele Abhängigkeiten mitbringen? So ein Abschnitt wie: Zusatzprogramme: In die Phylosophie von Openbox als minimalistischen Fenstermanager passen z.B.: könnte die Benutzer nicht zuletzt auch animieren weiter durch das Wiki zu stöbern. --Peter Littmann (Diskussion) 06:54, 6. Jun. 2019 (CEST)
- mc natürlich im Terminal, gibt es ja auch bei Openbox ;) Und der Rest, ich weiss nicht recht: als Kompromiss Extra-Seiten: Liste von Editoren, Liste von Mailprogrammen usw. und die dann mit Abschnitten "Leichtgewicht", "Schwergewicht" usw. So ähnlich, wie man es auch im Ubuntu-Wiki sieht. Weil, z.B. Claws-Mail könnte so auch auf einer xfce-Seite stehen, oder bei LXQT. Müsste man dann jedesmal aufführen. So könnte man vielleicht nur einen Verweis setzen, leichtgewichtiges Zeugs s. "Mailprogramme:Leichtgewichte" usw. Die Seite ist mir eh schon zu lang, und lange noch nicht fertig. Am liebsten hätte ich so openbox-menu und obmenu-generator auch ausgelagert: "Zum Bearbeiten eignen sich openbox-menu und obmenu-generator" jeweils mit einem Link auf die entsprechenden Seiten, wo dann alle Fein- und Gemeinheiten mehr oder weniger breit ausgewalzt werden können. Aber gut, wichtige Entscheidungen soll man immer erst überschlafen, auch wenn es leider schwer fällt. --Gosian (Diskussion) 20:46, 6. Jun. 2019 (CEST)
- Also ich habe jetzt mal einen Abschnitt Weitere Möglichkeiten eingefügt analog ubuntuusers.de und die Desktop-Hintergrund-Programme haben ihre eigene Seite erhalten. --Peter Littmann (Diskussion) 16:18, 8. Jun. 2019 (CEST)
- mc natürlich im Terminal, gibt es ja auch bei Openbox ;) Und der Rest, ich weiss nicht recht: als Kompromiss Extra-Seiten: Liste von Editoren, Liste von Mailprogrammen usw. und die dann mit Abschnitten "Leichtgewicht", "Schwergewicht" usw. So ähnlich, wie man es auch im Ubuntu-Wiki sieht. Weil, z.B. Claws-Mail könnte so auch auf einer xfce-Seite stehen, oder bei LXQT. Müsste man dann jedesmal aufführen. So könnte man vielleicht nur einen Verweis setzen, leichtgewichtiges Zeugs s. "Mailprogramme:Leichtgewichte" usw. Die Seite ist mir eh schon zu lang, und lange noch nicht fertig. Am liebsten hätte ich so openbox-menu und obmenu-generator auch ausgelagert: "Zum Bearbeiten eignen sich openbox-menu und obmenu-generator" jeweils mit einem Link auf die entsprechenden Seiten, wo dann alle Fein- und Gemeinheiten mehr oder weniger breit ausgewalzt werden können. Aber gut, wichtige Entscheidungen soll man immer erst überschlafen, auch wenn es leider schwer fällt. --Gosian (Diskussion) 20:46, 6. Jun. 2019 (CEST)
- Also nach dem Motto:Less is more. ;-) Ich hatte erstmal mit Xeyes und Xclock angefangen. MC mit GUI? Ich benutze den eigentlich nur im Terminal. Bei der Sinnfrage hast Du sicherlich Recht aber woher weiss ich und die anderen Benutzer welche Pakete zuviele Abhängigkeiten mitbringen? So ein Abschnitt wie: Zusatzprogramme: In die Phylosophie von Openbox als minimalistischen Fenstermanager passen z.B.: könnte die Benutzer nicht zuletzt auch animieren weiter durch das Wiki zu stöbern. --Peter Littmann (Diskussion) 06:54, 6. Jun. 2019 (CEST)
~/.config/openbox/autostart[Quelltext bearbeiten]
Hast Du eigentlich vor für autostart noch ein paar Beispiele zu bringen wie bei ubuntuusers.de? --Peter Littmann (Diskussion) 16:20, 8. Jun. 2019 (CEST)
- Nicht gerade ein paar, aber wenigstens ein Beispiel. Aber ich denke, diese Datei ist relativ unkompliziert, wenn man ein Beispiel sieht, kann man leicht andere davon ableiten. --Gosian (Diskussion) 21:32, 8. Jun. 2019 (CEST)