• Café
  • Pimp my Desktop - Screenshots

Ja, Du musst DWM rekompilieren. Und ja Anpassungen, weden über den Quellcode erledigt. Die Konfiguration wird als Headerdatei eingebunden, man muss C nicht beherrschen, um die Datei sicher verändern zu können.

Das Programm ist ein Client für mpd und heißt ncmpcpp.

Mit nicht gepackt meine ich, dass ich unter Leistungseinbußen zu leiden hatte, die ich weder erwartet, noch dauerhaft vertreten wollte. Das manifestierte sich in Form von kleinen bis mittelgroßen Lags, die einfach unschön waren und den Arbeitsflow gestört haben.
Also AwesomeWM läuft gut auf älterer Hardware, aber ein 'Centrino mobile' hat daran schon zu knabbern 😉
Wie sieht's mit der Mächtigkeit von dwm verglichen mit awesome aus? Kommt man mit der Headerdatei auf eine ähnliche Konfigurationstiefe (hab bisher quasi noch nie mit Headerdateien gearbeitet, daher kann ich das schlecht einschätzen, interessiert hat es mich jedoch schon länger).

Centrino mobile - müsste dann ein Pentium sein - so schwach auf der Brust oder so alt? 😉
Im vanilla dwm kann man eigentlich nicht viel konfigurieren, Shortcuts, Farben,
Tags auf denen Programme starten sollen und die Position der Statusbar. Zudem
gibt es zahlreiche Patches auf suckless.org und im englischen Archlinux-Forum
die aber teilweise nicht miteinander kompatibel sind so dass man für einige
Patches selbst Hand anlegen muss. Allerdings sind der gesamte dwb Sourcecode
nur etwa 2000 Zeilen C-Code, wenn man ein bisschen C kann dann kann man auch
relativ leicht neue Funktionen selbst implementieren.
Ovion schriebCentrino mobile - müsste dann ein Pentium sein - so schwach auf der Brust oder so alt?
'Dell Latitude|D610' Ich weiß nicht genau, wann der aktuell war, aber ich denke es war um die Zeit als WindowsXP mit SP1 der heißeste Scheiß war 😛

Schließe mich portix an, per default ist DWM eher spartanisch, aber direkt von Awesome komment fühlte ich mich sofort zurecht und heimisch. Es stimmt schon, dass die Konfigurationsmöglichkeiten beschränkt sind, wenn man sich nicht allzu gut in C auskennt, aber mit ein paar Patches, die meiner Meinung nach leicht einzupflegen und zu warten sind, lässt sich DWM komfortabel bedienen.

Wenn Du mal Interesse hast: Ich habe hier meine aktuelle Konfiguration veröffentlich, alle Patches sind als Kommentar beigefügt, bei suckless.org verfügbar und auch kompatibel zueinander.
Ich habe das Aussehen von KDE4 auf meinem Desktop bisschen geändert, das kam dabei raus:


Das Theme nennt sich Ghost (inspiriert von der GUI in Ghost In The Shell).
Plasma Theme: http://kde-look.org/content/show.php?content=107902
Color Scheme: http://kde-look.org/content/show.php?content=122201
Window Decoration Aurorae: http://kde-look.org/content/show.php?content=108675

Ich bin nur noch auf der Suche nach recht minimalistischen Satz an Icons die zu dem Blau/Cyan/Grün passen würden.

PS: Hintergrund ist von mir selbst gezeichnet/gemalt worden 😃.
fireandfuel schrieb PS: Hintergrund ist von mir selbst gezeichnet/gemalt worden 😃.
 Urgent! Upload very quickly! 
Sehr nice.
(Mehrere) fbpanel und Openbox:



Die ganzen Buttons sind für den Tablet-Modus des X201t…



…und werden im Porträt-Format wegrotiert, damit sie nicht stören.
Mal neue Tapete angebracht.
DE: Xfce4.10
GTK2/3/WM-Theme: GreyBird
Icons: Awoken mit sky-folders


Nur mit dem Hintergrundbild bin ich noch nicht zufrieden.
  • [gelöscht]

Auf meinen großen Systemen nutze ich wie bisher immer noch KDE aber auf meinem Notebook (Thinkpad T43) bin ich mittlerweile auf XFCE umgestiegen, denn KDE zieht doch sehr an der Performance.



GTK: Equinox Evolution Light
XFWM: Peaceful-Xfwm
Icons: Faenza

Mal schauen ob ich auf Arbeit auch auf XFCE umsteige.
  • [gelöscht]

Auf meinem "Großen" habe ich nun auch XFCE:

Ein paar Programme:

GTK.....: Zukitwo
XFWM4...: Zukitwo
Icons...: Faenza
Sobald das Xfwm4-Theme von Zukitwo aktiviert wurde, werden die Einstellungen beim Compositor ignoriert. Die Schatten unter den Fenstern werden zwangsweise aktiviert sowie bei Menüs entsprechend deaktiviert. Nach Anpassung der themerc klappte auch das wieder.

Zukitwo/xfwm4/themerc
button_offset=6
button_spacing=0
full_width_title=true
title_horizontal_offset=0
title_vertical_offset_active=0
title_vertical_offset_inactive=0
#title_shadow_active=true
title_shadow_inactive=true

#button_layout=O|HMC

active_text_color=#2c2c2c
inactive_text_color=#999999
inactive_text_shadow_color=#ffffff

placement_ratio=20
shadow_delta_height=2
shadow_delta_width=0
shadow_delta_x=0
shadow_delta_y=-10
shadow_opacity=50

resize_opacity=100
move_opacity=100
popup_opacity=100
#show_frame_shadow=true
#show_popup_shadow=false
Ovion schriebSchick. DWM wird via Quellcodeänderung (C?) und recompile verändert, oder?
Ich empfehle eine Installation über ABS 🙂
Nutze auch dwm läuft super bei mir und ich spar damit massig ram.
shibumi schriebIch empfehle eine Installation über ABS 🙂
Selbstredend, schließt sich ja nicht aus.
shibumi schriebNutze auch dwm läuft super bei mir und ich spar damit massig ram.
Gegenüber was? Bei KDE -> DWM ist das nicht wirklich ein Wunder. 😉

@Neuromantic
Danke übrigens für's uppen der config! Hab ich noch gar nicht gesagt.

Was passiert eigentlich, wenn ich beim Verändern des Codes einen Fehler mache, der keinen Compilerfehler wirft, DWM aber unbenutzbar macht. Gibt's da einen Fallback?
So wie ich das sehe, wird DWM ja über besagten Header, und wenn's weiter gehen soll, über eine direkte Quellcodeänderung angepasst. Wenn ich den fehlerhaften Code versehentlich über meinen bestehenden DWM drüberschreibe, bekomme ich dann ein Problem?
Ovion schriebGegenüber was? Bei KDE -> DWM ist das nicht wirklich ein Wunder. 😉
Gegenüber Awesome und KDE sowieso wie aufgeblasen KDE ist.
Ovion schriebWas passiert eigentlich, wenn ich beim Verändern des Codes einen Fehler mache, der keinen Compilerfehler wirft, DWM aber unbenutzbar macht. Gibt's da einen Fallback?
So wie ich das sehe, wird DWM ja über besagten Header, und wenn's weiter gehen soll, über eine direkte Quellcodeänderung angepasst. Wenn ich den fehlerhaften Code versehentlich über meinen bestehenden DWM drüberschreibe, bekomme ich dann ein Problem?
Ich würde nur in der header-datei arbeiten. Quellcode-Änderungen im übrigen Teil von DWM empfehle ich nicht unbedingt. Rein theoretisch lässt sich fast alles über header machen. Und als fallback lege ich vor jeder Änderung in der headerdatei ne Kopie davon an.
Ovion schriebWas passiert eigentlich, wenn ich beim Verändern des Codes einen Fehler mache, der keinen Compilerfehler wirft, DWM aber unbenutzbar macht. Gibt's da einen Fallback?
Dann stürzt er ab oder verhält sich halt „falsch“. Und im „dümmsten“ Fall kommst du nicht mehr ins X.
Ovion schriebSo wie ich das sehe, wird DWM ja über besagten Header, und wenn's weiter gehen soll, über eine direkte Quellcodeänderung angepasst. Wenn ich den fehlerhaften Code versehentlich über meinen bestehenden DWM drüberschreibe, bekomme ich dann ein Problem?
Wenn „kein X“ für dich ein Problem ist, dann ja. 🙂 Wenn du tiefer einsteigen willst als nur ein paar Hotkeys in der config.h zu setzen, dann klone dir einfach das Git-Repo von dwm und committe da bei dir lokal rein. Dann verlierst du keine Stände und alles ist sauber. Wenn du sowieso schon ein dotfiles-Repo oder so hast, dann würde ich das auch für die config.h verwenden.

Und dwm würde ich nie als Paket via ABS installieren, wenn nur ich alleine ihn benutze. Wozu auch? Man editiert dann halt doch häufig in der config.h oder dem Code rum und muss ihn dann neu kompilieren. Der Paketbau ist da ein ziemlich unnötiger Zwischenschritt. Gib einfach in deiner .xinitrc den vollen Pfad zur dwm-Binary an und gut ist’s.
Wenn man selber neue Funktionen schreibt dann empfiehlt es sich Xephyr zu nutzen, damit kann man dwm in einer laufenden X-Session testen, beim einfachen editieren der config.h kann man aber eigentlich kaum etwas kaputt machen, ist auch nicht schwieriger als eine xml-datei oder andere Textdateien zu bearbeiten.

dwm als Paket zu bauen ergibt gerade bei einem Mehrbenutzer-System keinen Sinn
weil dann alle gezwungen sind die gleiche Konfiguration zu verwenden. Bei einem
Einzelnutzer-System ergibt es allerdings imho auch keinen Sinn weil es viel
umständlicher ist. Ich habe einen Symlink von dwm nach ~/bin welches in meinem
PATH ist.
Auch wieder wahr, wenn's ohnehin nur ein binary ist, dann reicht das ja auch. Bin reflexartig auf dem Trip "keine Software am Paketmanager vorbei", aber ein einzelnes Binary bekommt man ja auch wieder problemlos aus dem System, wenn man's nicht mehr braucht.

Wie lange dauert ein DWM-Compile eigentlich?
Ovion schrieb… aber ein einzelnes Binary bekommt man ja auch wieder problemlos aus dem System, wenn man's nicht mehr braucht.
Trotzdem macht man das nicht 🙂
~/source/dwm-6.0 >time make 
dwm build options:
CC dwm.c
CFLAGS   = -std=c99 -pedantic -Wall -Os -I. -I/usr/include -I/usr/X11R6/include -DVERSION="6.0" -DXINERAMA
LDFLAGS  = -s -L/usr/lib -lc -L/usr/X11R6/lib -lX11 -L/usr/X11R6/lib -lXinerama
CC       = cc
dwm.c: In function 'keypress':
dwm.c:1138:2: warning: 'XKeycodeToKeysym' is deprecated (declared at /usr/include/X11/Xlib.h:1695) [-Wdeprecated-declarations]
  keysym = XKeycodeToKeysym(dpy, (KeyCode)ev->keycode, 0);
  ^
CC -o dwm

real    0m1.471s
user    0m1.307s
sys     0m0.097s
Der Rechner ist jetzt 6 Jahre alt, ist momentan auch nicht vanilla dwm, auf aktuellen Systemen sollte es etwas schneller gehen.
@Dirk: ich würde dir bei jeder anderen Software Recht geben, bei dwm ist es einfach sinnlos, man sollte nur nicht dwm am Paketmanager vorbei nach /usr/bin installieren.
Abgesehen davon installiert man nicht am Paketmanager vorbei wenn man den Pfad zu dwm direkt in die .xinitrc schreibt weil man dwm dann gar nicht installiert.
portix schriebreal 0m1.471s
user 0m1.307s
sys 0m0.097s
Nicht schlecht. Kleine Frage zum Lesen: user + sys < real, ist die Gesamtzeit also alles drei zusammen oder kann ich kein Kopfrechnen mehr?

Kann ich dwm eigentlich recompilen und mit der neuen Konfiguration neustarten, sodass geöffnete Fenster erhalten bleiben? Oder muss ich alles ausschalten und dann neustarten (weil das gesamte Binary und nicht nur die Konfiguration neugestartet werden muss, wie bei awesome)?
Die Gesamtzeit ist real. Normalerweise beendet sich der Xserver wenn man dwm beendet, man kann das aber verhindern indem man den Aufruf in eine Schleife packt.
while :; do 
    dwm 
done
Dann muss man den Xserver explizit beenden um wieder in die Konsole zu kommen.