Konfiguraton fvwm2

Danke, ralli :)

Sieht anständig und vernünftig aus.
An einem Pinguin könnte mir sowas gefallen, auf OpenBSD möchte ich die Schlichtheit des Default-fvwm2 möglichst bewahren.
 
Danke, ralli :)

Sieht anständig und vernünftig aus.
An einem Pinguin könnte mir sowas gefallen, auf OpenBSD möchte ich die Schlichtheit des Default-fvwm2 möglichst bewahren.
Sehr gerne. Ja für OpenBSD ist das (fast) ein Stilbruch. Aber ich wollte das nicht weiter vertiefen, sondern lediglich aufzeigen, das alles vom Design her möglich ist.
 
Anliegen 1 :
Nun hätte ich darin auch gerne häufig genutzte, nachinstallierte Programme (zB firefox, nano) in diesem Menus - anstatt sie per xterm zu starten.

Schau Dir bitte mal fvwm-menu-desktop an. Das ist ein perl-Skript, dass fvwm 2.6.5 beiliegt und welches man per Kommando PipeRead in die
~/.fvwm2rc bei den "AddToMenu" Einträgen dazufügen kann. Wenn auf Deinem System sowieso schon .desktop-Dateien von gnome/kde in
/usr/share/applications/ oder ähnlichem rumliegen, dann nutzt fvwm-menu-desktop diese, um die entsprechenden nachinstallierten Programm
automatisch in das Menue zu integrieren.

Mit PipeRead kann man noch mehr so dynamischen Kram machen. Z.B. dass der fvwm2 über das Medien-Verzeichnis geht und für jede Datei
dort einen Menue-Eintrag macht.

Gruesze
hunderteins
 
Ich kenne fvwm nicht, aber ich habe so ein "mach mir ein Standardmenu mit den üblichen Kategorien und allen halbwegs standardmäßig installierten Applikationen Menu" utility für jwm geschrieben.
Wenn fvwm nicht allzu unterschiedlich ist und du Python kannst, dann könntest du damit recht einfach eine entsprechende Version für fvwm stricken. Der aufwendige Teil ist ja nicht, das Menü zu basteln; das sollte recht einfach an fvwm anzupassen sein.

Oder du nimmst gleich jwm. Kann auch alles und ich kann dir sagen, wie du 2 oder 5 oder 9 Desktops einstellen kannst *g
 
Schau Dir bitte mal fvwm-menu-desktop an. Das ist ein perl-Skript, dass fvwm 2.6.5 beiliegt und welches man per Kommando PipeRead in die
~/.fvwm2rc bei den "AddToMenu" Einträgen dazufügen kann. Wenn auf Deinem System sowieso schon .desktop-Dateien von gnome/kde in
/usr/share/applications/ oder ähnlichem rumliegen, dann nutzt fvwm-menu-desktop diese, um die entsprechenden nachinstallierten Programm
automatisch in das Menue zu integrieren.

Mit PipeRead kann man noch mehr so dynamischen Kram machen. Z.B. dass der fvwm2 über das Medien-Verzeichnis geht und für jede Datei
dort einen Menue-Eintrag macht.

Gruesze
hunderteins
Du hattest zwar nicht mich gemeint, aber trotzdem Danke für den Tipp. Jetzt schaue ich mir das an, hatte eh vor, die fvwm Module nach und nach durch zu arbeiten.
 
Ich kenne fvwm nicht, aber ich habe so ein "mach mir ein Standardmenu mit den üblichen Kategorien und allen halbwegs standardmäßig installierten Applikationen Menu" utility für jwm geschrieben.
Wenn fvwm nicht allzu unterschiedlich ist und du Python kannst, dann könntest du damit recht einfach eine entsprechende Version für fvwm stricken. Der aufwendige Teil ist ja nicht, das Menü zu basteln; das sollte recht einfach an fvwm anzupassen sein.

Oder du nimmst gleich jwm. Kann auch alles und ich kann dir sagen, wie du 2 oder 5 oder 9 Desktops einstellen kannst *g
Wie ich auch schon schrieb, die Konfiguration und damit die Anpassung an die persönlichen Bedürfnisse passiert ja nur ein einziges Mal. Ich habe für alle gängigen Windowmanager (Openmotif mwm, fvwm2, jwm, Openbox, Fluxbox, Icewm und Wmaker fertig angepaßte Konfigurationsdateien. War zwar viel Arbeit, aber jetzt bin ich damit durch. Der jwm gefällt mir auch sehr gut, er ist sehr resourcenschonend, schnell und stabil und ist überschaubar zu konfigurieren.
 
Wie ich auch schon schrieb, die Konfiguration und damit die Anpassung an die persönlichen Bedürfnisse passiert ja nur ein einziges Mal. Ich habe für alle gängigen Windowmanager (Openmotif mwm, fvwm2, jwm, Openbox, Fluxbox, Icewm und Wmaker fertig angepaßte Konfigurationsdateien. War zwar viel Arbeit, aber jetzt bin ich damit durch. Der jwm gefällt mir auch sehr gut, er ist sehr resourcenschonend, schnell und stabil und ist überschaubar zu konfigurieren.

Falls ich kapiert habe, wie Zeug hochladen hier geht, dann ...

hast du hier einen screenshot, wie so ein von jwmamenu erstelltes Menu aussehen kann, das Python Program "jwmamenu" und (englische) Doku. Einbinden kannst du es (in jwm) entweder direkt unter der menu root oder innerhalb eines menus. Details, auch zur Konfiguration (das Dingelchen ist recht flexibel) findest du in der beigefügten Doku.
Falls du es an fvwm anpassen willst, kannst du es fast komplett übernehmen. Nur im untersten Teil (unterhalb von ('# now, generate jwm menu include') müsstest du Änderungen für fvwm vornehmen. Ich kenne fvwm nicht und kann nur bedingt dabei helfen, aber bei konkreten Fragen werde ich's zumindest versuchen.

Disclaimer/Anmerkung: Ich bin ziemlich Buntzeug-ignorant und ergo interessiert mich der volle xdg Standard null. Meine xdg Annahme ist, dass eine Applikation ihr .desktop file in einem Standard Verzeichnis (meist /usr/share/applications, ist aber konfigurierbar) ablegt und irgendwelche kde, gnome oder sonstige Spezialwürste interessieren mich nicht. Geh also davon aus, dass einige Exoten ihr Zeug in wer weiss welche exotischen xdg Verzeichnisse legen und jwmamenu sie nicht findet. Die Lösung ist simpel: Ein soft link des .desktop files ins Standard Verzeichnis.

Bei mir persönlich habe ich allerdings alle installierten Applikationen problemlos automatisch gefunden (und sogar einige fürs Menu sinnlose, siehe Doku).

Laufen tut es extrem flott. Bei einem jwm restart ist praktisch nicht feststellbar, das da noch jwmamenu zusätzlich aufgerufen wird. Falls du sehr selten neue Applikationen installierst (oder die Anpassung an fvwm testest), kann du jwmamenu auch einfach so im Terminal aufrufen und den output in z.B. menu.tst leiten, bzw. fest/statisch in deine window manager config einbinden.
Wenn ich mal eine neue Applikation installiert habe, lasse ich einfach jwm restarten (dauert kaum ne Sekunde) und hab die neue App im menu.

Eine Kleinigkeit noch, die noch nicht in der Doku steht: oft ist das exec in .desktop files mit target specifiern wie '%F'. Das ist praktisch für file manager aber in menus unschön, weil z.B. der editor dann mit einem geöffneten file '%F' startet. Das ist in der aktuellen Version nun geregelt.

Viel Spass und bei Fragen melde dich einfach - R

P.S. Ich musste die python datei mit der Endung "txt" versehen, um sie hochladen zu können. Einfach die Endung wegmachen und dann chmod +x jwmamenu
 

Anhänge

  • jwmamenu-sshot.jpg
    jwmamenu-sshot.jpg
    22,3 KB · Aufrufe: 486
  • jwmamenu.txt
    5 KB · Aufrufe: 387
So, hier noch eine jwmamenu.txt, diesmal ist es die doku.
Sorry, aber ich kenne das System hier noch nicht und weiss es noch nicht besser zu machen.
 

Anhänge

  • jwmamenu.txt
    7,5 KB · Aufrufe: 619
Schau Dir bitte mal fvwm-menu-desktop an. Das ist ein perl-Skript, dass fvwm 2.6.5 beiliegt und welches man per Kommando PipeRead in die
~/.fvwm2rc bei den "AddToMenu" Einträgen dazufügen kann. Wenn auf Deinem System sowieso schon .desktop-Dateien von gnome/kde in
/usr/share/applications/ oder ähnlichem rumliegen, dann nutzt fvwm-menu-desktop diese, um die entsprechenden nachinstallierten Programm
automatisch in das Menue zu integrieren.

Danke für diesen Hinweis :)

Wenn fvwm nicht allzu unterschiedlich ist und du Python kannst, dann könntest du damit recht einfach eine entsprechende Version für fvwm stricken. Der aufwendige Teil ist ja nicht, das Menü zu basteln; das sollte recht einfach an fvwm anzupassen sein.

Phyton kann ich leider nicht. jwm wäre natürlich auch eine Alternative gewesen und standardmässig dabei.
fvwm wirkt mir sehr sympathisch und wollte daher quasi default bleiben. Stimmt schon, die eigentlichen Anpassungen (im fvwm2) waren das geringste an Arbeit.
 
Gute Arbeit rmoe.:) Auf die Idee kam ich auch schon, mit Java einen Konfigurator für jwm oder andere Windowmanager zu schreiben. Allerdings erschien mir der Aufwand dann letztendlich doch zu groß. Für fvwm2 wäre das dann schon ein größeres Projekt geworden. Die Strukturen der Konfigurationsdateien sind überwiegend dann doch ähnlich (bis auf fvwm2, dessen Leistungsumfang dann doch alles sprengt) in einer xml Datei abgelegt und das Editieren und Ändern geht doch ziemlich flott. Hier spendiere ich mal meine Konfigurationsdatei für jwm. Das Design ist bewußt auch schlicht gehalten.
 

Anhänge

  • jwmrc.txt
    5,5 KB · Aufrufe: 422
  • jwm.png
    jwm.png
    26,4 KB · Aufrufe: 496
Phyton kann ich leider nicht. jwm wäre natürlich auch eine Alternative gewesen und standardmässig dabei.
fvwm wirkt mir sehr sympathisch und wollte daher quasi default bleiben. Stimmt schon, die eigentlichen Anpassungen (im fvwm2) waren das geringste an Arbeit.

Also, was ich dir noch konkret anbieten kann ist, den Teil (ganz unten) von jwmamenu, der letztlich das menu generiert, so ausgiebig zu kommentieren, dass du auch ohne Ahnung von Python dein fvwm menu hinbekommst.
Das macht insofern Sinn, als ja alle diese menus, wenn auch in unterschiedlicher Notation, im Grunde dasselbe beinhalten. Kategorien mit Applikationen darin.

Einzige Voraussetzung natürlich: Du musst fvwm kennen und wissen, wie das seine Menueinträge haben will.
 
Gute Arbeit rmoe.:) Auf die Idee kam ich auch schon, mit Java einen Konfigurator für jwm oder andere Windowmanager zu schreiben. Allerdings erschien mir der Aufwand dann letztendlich doch zu groß. Für fvwm2 wäre das dann schon ein größeres Projekt geworden. Die Strukturen der Konfigurationsdateien sind überwiegend dann doch ähnlich (bis auf fvwm2, dessen Leistungsumfang dann doch alles sprengt) in einer xml Datei abgelegt und das Editieren und Ändern geht doch ziemlich flott. Hier spendiere ich mal meine Konfigurationsdatei für jwm. Das Design ist bewußt auch schlicht gehalten.

Danke, ralli.

Bei mir fing es damit an, dass ich mal openbox (auf linux) genutzt habe und dafür etwas wie mein jwmamenu ("openbox-menu" oder so ähnlich) hatte. Das war von einem Franzosen und hübsch gemacht, wenn auch viel zu aufwendig und so, dass es unter FreeBSD beim Bauen würgte.
So enstanden zwei Antriebe. Zum einen ganz pragmatisch so etwas auch für jwm und portabel zu haben und zum anderen etwas zu machen, das "ideologisch" zu den schlanken window managern passte, also klein war, formal sehr simpel und simpel zu konfigurieren aber mit einem netten Leistungsumfang und etwas Komfort. In python deshalb, weil alles jenseits scripting unangemessen aufwendig wäre, gebaut werden müsste (was manche Anfänger abschreckt und oft build probleme bringt), python überall verfügbar und weit verbreitet ist und ich shell scripts nur für *sehr* primitive simple Sachen verwende (diese Lektion habe ich spätestens bei einem 500+ Zeilen Installer mal gelernt. So maso, mehr als 20, 25 Zeilen in shell script zu machen, bin ich nicht).

Übrigens, nur als Randbemerkung: Python ist ganz schön fett geworden (wenn ich da so an Python 1.5 zurückdenke ...). Aber obwohl es eine Gazillion interpretierte Sprachen gibt, ist leider wenig brauchbares dabei. Lua wäre ja schön klein, ist aber nicht mein Ding.

Übrigens, mal ganz pragmatisch betrachtet: Sich mal einen Abend hinzusetzen und etwas wie jwmamenu zu bauen ist letztlich effizienter als zig Leuten jeweils zu erklären, wie sie ihre Applikationen ins Menu kriegen ...
 
Danke, ralli.

Bei mir fing es damit an, dass ich mal openbox (auf linux) genutzt habe und dafür etwas wie mein jwmamenu ("openbox-menu" oder so ähnlich) hatte. Das war von einem Franzosen und hübsch gemacht, wenn auch viel zu aufwendig und so, dass es unter FreeBSD beim Bauen würgte.
So enstanden zwei Antriebe. Zum einen ganz pragmatisch so etwas auch für jwm und portabel zu haben und zum anderen etwas zu machen, das "ideologisch" zu den schlanken window managern passte, also klein war, formal sehr simpel und simpel zu konfigurieren aber mit einem netten Leistungsumfang und etwas Komfort. In python deshalb, weil alles jenseits scripting unangemessen aufwendig wäre, gebaut werden müsste (was manche Anfänger abschreckt und oft build probleme bringt), python überall verfügbar und weit verbreitet ist und ich shell scripts nur für *sehr* primitive simple Sachen verwende (diese Lektion habe ich spätestens bei einem 500+ Zeilen Installer mal gelernt. So maso, mehr als 20, 25 Zeilen in shell script zu machen, bin ich nicht).

Übrigens, nur als Randbemerkung: Python ist ganz schön fett geworden (wenn ich da so an Python 1.5 zurückdenke ...). Aber obwohl es eine Gazillion interpretierte Sprachen gibt, ist leider wenig brauchbares dabei. Lua wäre ja schön klein, ist aber nicht mein Ding.

Übrigens, mal ganz pragmatisch betrachtet: Sich mal einen Abend hinzusetzen und etwas wie jwmamenu zu bauen ist letztlich effizienter als zig Leuten jeweils zu erklären, wie sie ihre Applikationen ins Menu kriegen ...
Das ist leider nicht pythonspezifisch. Vieles ist zu fett, zu aufgebläht worden, ich denke da an Qt, an Java, an NetBeans und vielen anderen. Weniger wäre oft mehr.;)
 
Ich habe in der letzten Woche mal einige Windowsmanager genauer unter die Lupe genommen und gecheckt. Das Ergebnis hat mich dann doch überrascht, der Speicherverbrauch war nur marginal unterschiedlich:

Hier das Ergebnis:

Resourcenverbrauch Windowmanager unter OpenBSD 5.3:

Xterm - top

OpenMotif mwm : 27/73

jwm : 28/75

fvwm2 : 35/93

icewm : 31/85

wmaker : 31/81

openbox : 32/92

fluxbox : 34/85

Enlightenment E17 : 56/144

Zum Vergleich ein Desktop:

KDE3 : 67/179

Der Speicherverbrauch unter FreBSD 9.3 lag nur geringfügig höher, was durch den propertiären Nvvidia Treiber bedingt sein könnte.

Hintergrundbilder habe ich nicht beim Starten geladen, damit gleiche Bedingungen vorlagen.

Jeder WM lief stabil, flüssig und schnell. Die meisten unterscheiden sich nur durch Ihr standardmäßiges Design. Auch die Konfiguration ist oft ähnlich. Openbox bringt ja bereits Konfigurationswerkzeuge mit, wenn obmenu und obconfig mitinstalliert wurden. Das erleichtert für Einsteiger die Sache schon. Icewm ist das Chamäleon unter den WM. Mit einigen Designanpassungen kannst Du damit auf Retro machen wie Windows XP oder Windows 95. Am mächtigsten ist fvwm2, der aber um den gesamten Leistungsumfang zu nutzen, einiges an Einarbeitungsszeit kostet. Die meisten WM sind recht gut dokumentiert. Und letztlich sind alle WM noch nicht dienstunfähig, weil sei auf älteren Rechnern noch sehr gut Ihren Dienst versehen. Probleme gab es mit jwm, wenn ich im Terminal meine externe USB PLatte mountete, da dachte ich es zersägt mir die Hardware. Auch Enlightenment (allerdings nur unter FreeBSD 9.3) muckte ein wenig rum, plötzlich war der Filemanager nach einem Neustart weg, und das schlimmste war, das es abstürzte und ich FreeBSD 9.3 neu installieren mußte. Negativ unter FreeBSD 9.3 empfinde ich, das die Lautstärke bei Multimediaanwendungen in keinen der genannten WM zu steuern war. Das wiederum funktionierte bei mir bei OpenBSD einwandfrei. So, das war ein kleines Fazit meiner Erfahrungen, die ich gerne mit euch teile.

Die Vielfalt ist dann doch schön, weil dann auch für jeden etwas dabei ist, was Ihm möglicherweise gefällt.:D
 
Genau, wenn's schon klein sein soll, warum nicht was aktuelles? Ich bin mit spectrwm sehr zufrieden. Ich will halt nur Fenster anzeigen und das möglichst komfortabel!

Da braucht's auch nicht unbedingt eine Konfiguration, um gut damit arbeiten zu können.
 
Zu bedenken bei solchen Vergleichen ist natürlich immer auch, was so alles im Paket ist. Bei OB z.B. muss man ein taskbar erst dazu installieren (z.B. tint2), bei jwm ist es schon eingebaut (was aber auch ein Nachteil sein kann, wenn man keins will). Und gerade bei den größeren, so ab lxde aufwärts, ist natürlich fast immer ein desktop manager am Laufen. Und bei den ganz Großen wie kde dann noch so einiges anderes, z.B. nepomuk, die irre Resourcen verschlingen.

Bei mir sagt conky, dass ein ungestrippter Standard OB ca. 10, 15 MB mehr Speicher verbraucht als jwm. Bei xfce4 kommen nochmal etwa 50MB dazu und gnome und kde4 liegen klar im deutlich ungesunden Bereich; die fressen 150+ MB mehr weg.

Was mich an jwm irritiert ist, dass es anscheinend weitgehend inaktiv ist, der Autor nicht reagiert und nirgends aktiv ist (was jwm angeht). OpenBox scheint insgesamt der beste Kompromiss für meinen Bedarf zu sein. Und bei beiden merkt man den Unterschied zu xfce4 oder gar gnome *sehr* deutlich auch beim Start.
 
Vergleiche hinken immer, und natürlich ist dieser wmcheck nicht repräsentativ, dazu herrschen zu unterschiedliche Bedingungen beim Start. Er diente mir lediglich dazu, mir noch ein Mal einen groben Überblick zu verschaffen. Mein Favorit ist openbox, der doch sehr ausgereift ist und der fvwm hat es auch in sich. Aber das ist das Gute daran, das das jeder für sich selbst entscheiden darf. Und mir ist es auch nicht peinlich, diese kleine Übersicht gepostet zu haben, weil es möglicherweise bei Einsteigern eine kleine Entscheidungshilfe sein könnte. Der pädagogische Mehrwert eines solchen wmcheck besteht darin, sich mit allem auseinandergesetzt zu haben und deshalb auch mitreden zu können und eine Aussage hinsichtlich Vor- oder Nachteilen zu treffen. Theoretisieren kann jeder. Bei modernen Rechnern spielt der Speicherverbrauch eh keine Rolle mehr. Für mich ist das jetzt hier abgeschlossen. Denn es war ja schon OT. Das ist leider nicht immer zu verhindern, wenn es nicht oberflächlich bleiben soll.
 
Wenn du meinen Beitrag als Angriff aufgefasst haben solltest (es macht mir den Eindruck), möchte ich dir klar sagen, dass er so keineswegs gemeint war, Ralli!

Wie du von meinen tools weisst, theoretisiere ich keineswegs nur sondern arbeite mit beiden (und noch anderen) wm, wobei ich gerade jwm, ob und xfce recht ausführlich "angeschaut" (mich damit befasst) habe.

Ich finde deine Übersicht durchaus gut und nützlich, allein schon weil ich nur eine einzige vergleichbar umfassende kenne. Ich wollte nur darauf hinweisen, dass gelegentliche Äusserungen (nicht von dir) wie "openbox ist viel kleiner als xfce" insofern trügerisch sind als die Grundausstattung der diversen wm recht unterschiedlich ist.

Bedingt durch die teilweise gerade absurden Verquickungen, gerade von der freedesktop Seite her, mit diversen busses und kits wächst der bloat, den man als user erst mal dem wm anlastet ziemlich schnell ziemlich heftig.
Das heisst auch, das jwm oder openbox nicht unbedingt deshalb resourcenschonender sind, weil die Autoren besser programmieren können als z.B. die von kde, sondern vor allem durch das Drumherum im Hintergrund.

Ich komme da nochmal auf meine jwm und ob amenu tools zurück, die den Punkt auch zeigen.

Die Kernaufgabe, nämlich Applikationen zu finden und in einer bestimmten Form (xml) zu präsentieren/injizieren ist eigentlich relativ klar und simpel (in gewisser Weise wie ein wm). Allerdings musste ich schnell feststellen, dass ich, um alle icons mitzugeben, ziemlich fette xdg/freedesktop dependencies einbinden und so ein eigentlich simples Programm stark aufblähen und die Installation wegen der Abhängigkeiten deutlich komplizieren müsste.

Klar, bei gnome oder kde kommt der bloat auch von featuritis. Aber bei den kleineren wm dürfte der größte Teil im eben beschriebenen Phänomen, im wesentlich in Konformität mit freedesktop "standards" liegen, die alles stark aufblähen (und herzlich wenig dafür leisten).
Deshalb erwähnte ich das eingebaute taskbar von jwm, weil die openbox Kombi mit tint alleine nur für die Kombi schon fett Resourcen verschwenden muss.

Anders und deutlicher ausgedrückt: Von redhat (und deren Leuten überall, u.a. bei systemd) kommt, mal deutlich formuliert, eine ganze Menge von dem bloat und Mist, für den man microsoft immer geschimpft hat.
 
Nein rmoe, ich habe Deinen Beitrag nicht als Angriff aufgefasst. Ich bin zwar sensibel, aber keine Mimose. Wer seine Meinung im Diskurs öffentlich macht, darf nicht nur auf Zuspruch hoffen, denn sie kann (und darf) auch Gegenwind erzeugen. Aber genau das macht ja die unterschiedlichen Meinungen aus, die Vielfalt, die ich als Bereicherung empfinde. Ansonsten hast Du es auf den Punkt gebracht und ich habe dem nichts mehr hinzuzufügen. Deshalb stimme ich Dir voll und ganz zu. Minimalistische Installationen mittels Windowsmanager haben auch Ihren Reiz, aber es muß auch sehr viel nachinstalliert werden, um dann noch produktiv damit zu arbeiten. Und das ist auch zeitintensiv. Desktopsysteme hingegen bieten alles aus einem Guß, machen weniger Arbeit und sind daher auch schneller installiert. Das Schöne und damit ein Alleinstellungsmerkmal bei Unix oder Linux artigen Systemen ist halt nach wie vor die Vielfalt und wir dürfen selber wählen, was unseren Bedürfnissen in Funktionalität und Ästhetik entspricht.
 
@ralli
Meine Frage war eine ernst gemeinte neugierige Bitte und keine Kritik.
Das glaube ich gerne und habe es auch nicht als Kritik wahrgenommen. Außerdem ist konstruktive Kritik immer erwünscht und natürlich auch willkommen. Dwm und i3 kenne ich nicht, werde es mir aber mal bei Gelegenheit anschauen. da gibt dann glaube ich auch noch Awesome, oder? Ja, die Auswahl ist immens und gewiß ist für jeden Geschmack etwas dabei.
 
Seit gnome und kde sich zu ziemlichen Katastrophen entwickeln, bin ich wieder recht neugierig geworden und spiele aktuell mit fvwm, cde und i3 rum, daher die Frage.

Letztendlich merke ich zwischen dwm und i3 keinen nennenswerten Unterschied, i3 klingt aber cooler. ;)
 
Zurück
Oben