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.

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.

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.

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 🙂

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.

Ovion schriebKleine Frage zum Lesen: user + sys < real, ist die Gesamtzeit also alles drei zusammen oder kann ich kein Kopfrechnen mehr?

Gibt ja auch Zeiten, in denen ein Prozess nicht läuft, die reale Zeit aber weiterläuft. 🙂

$ time sleep 1

real    0m1.002s
user    0m0.000s
sys     0m0.000s

Ach so, ich dachte, Sleepzeiten würden nicht berücksichtig, weil das eigentlich nicht zum Prozess gehört, aber auf der anderen Seite macht dann die Unterscheidung zwischen Prozesszeit (user + sys) und realer Zeit sehr viel mehr Sinn.

@portix
Eine sehr interessante Idee. Wird aber, denke ich, irgendwie ein bisschen blöd, wenn ich dann ein laufzeitfehlerhaftes Binary produziere, dass in einer unendlichen Schleife ständig abschmiert. 🙂
Man könnte den Code natürlich noch mit einer Überprüfung des Exit-Codes versehen und da evtl. eine Variable im while überprüfen, das würde vermutlich gehen. Den X-Server kann man noch sauber beenden, wenn er in einer unendlichen Schleife hängt? Oder muss man da mit kill rangehen?

noerrorstate = true
while noerrorstate:; do 
    dwm
    if [[ $? != 0]]; then
        noerrorstate = false
    fi
done

Müsste so funktionieren, oder?