dwm, urxvt, qingy, xmodmap, surf und ein Thinkpad

In diesem Beitrag geht es noch ein wenig um ein paar wissenswerte Funktionen und Hilfsprogramme zum Dynamic Window Manager und um ein paar Merkwürdigkeiten und Einstellungen rund um den Thinkpad 600.

Qingy

Da ich dieses Jahr vor neuen Anwendungen und ein paar Veränderungen keinen Halt gemacht habe, durften natürlich Loginmanager für die Konsole auch nicht fehlen. Qingy ist darunter eine interessante Alternative und ein Mittelding zwischen der minimalen Startx-Lösung und einem voll ausgestatteten Loginmanager wie Gnomes GDM3, wenn man sich in eine grafische X-Umgebung einloggen möchte.
DWM und Qingy scheinen aber nicht richtig zueinander zu finden. Zumindest konnte ich Qingy nicht dazu bewegen eine Login-Shell zu starten, die meine gesamten Umgebungsvariablen wie z.B. die Spracheinstellungen berücksichtigt. Das führte leider dazu, dass Umlaute nicht dargestellt werden konnten.
Mit diesem scheinbar esoterischen Problem war ich aber nicht allein und das Arch-Linux-Wiki hatte dazu mal wieder einen passenden Tipp, z.B. Qingy über eine sogenannte Custom Session zu starten. Ein grafischer Loginmanager wie Qingy berücksichtigt dabei die Datei .xsession. Der Befehl exec zsh -l -c "dwm" brachte mich aber leider nicht ans Ziel.
Lange Rede kurzer Sinn, ich bin wieder ohne Loginmanager unterwegs und habe mir eine Anwendung gespart. Im Gegensatz zu den grafischen Pendants berücksichtigt die Startx/Xinit-Lösung die im Home-Verzeichnis versteckte .xinitrc, was später noch nützlich sein sollte.

rxvt-unicode-256color

Ich greife schon etwas vor, denn ich habe auch einen Backport von rxvt-unicode-256color erstellt. Die 256-Farben-Version von urxvt befindet sich leider nicht in Squeeze. Da ich aber, abgesehen vom Toshiba 220cs, überall schon rxvt-unicode mit der Solarized-Farbpalette benutze, durfte es auf dem Thinkpad auch nicht fehlen und war dank der schon bestehenden Config-Dateien auch schnell eingerichtet.
Mir ist aber aufgefallen, dass die Xft-Schriftarten das Scrollen sehr verlangsamen, was entweder an der Grafikkarte, den Treibern oder auch einer Terminaleinstellung liegen könnte. Da es aber sowohl in Xterm als auch in Urxvt auftrat, bin ich mir bei letzterem nicht so sicher. In einem Forum meine ich gelesen zu haben, dass
urxvt*buffered: false
in der .Xdefaults helfen solle. Mir half hingegen der Wechsel zu einer Bitmap Schrift. Einfach folgendes zur .Xdefaults hinzufügen:

urxvt*font: -xos4-terminus-medium-*-*-*-12-*-*-*-*-*-*-*
urxvt*boldFont: -xos4-terminus-bold-*-*-*-12-*-*-*-*-*-*-*

xmodmap

Mit Hilfe von xmodmap lässt sich die Tastaturbelegung ändern, indem die kerneleigenen Keycodes in sogenannte Keysyms des X-Servers konvertiert werden. Einen guten Überblick über die Thematik findet sich unter dem Stichwort Xmodmap im deutschen ArchLinux-Wiki.
Nachdem ich beim Neukompilieren die MOD-Taste von Mod1 (ALT) auf Mod4(Super) geändert hatte, musste ich noch das Problem lösen wie ich nun bei einem Laptop ohne Super-Taste die Tastenkombinationen ausführen konnte. Als Alternative bot sich z.B. die AltGr-Taste an.

xmodmap -e "keycode 108 = Super_L"

Das funktionierte auch prima, bis ich wieder einmal | als Zeichen benötigte. 🙄
Kein Problem nehmen wir die rechte Strg Taste.

xmodmap -e "keycode 105 = Super_L"

Leider Fehlanzeige, ganz so trivial ist xmodmap dann doch nicht. Vorher war z.B. noch das notwendig:

xmodmap -e "remove control = Control_R"
xmodmap -e "keycode 105 = Super_L"
xmodmap -e "remove mod4 = Super_L"
xmodmap -e "add mod4 = Super_L"

Wer nun schon voll Feuer und Flamme ist und die Enter-Taste auf die Löschen-Taste, Backspace zu Space und Shift zu ESC auf dem Rechner des Arbeitskollegen ummappen möchte, sollte sich auf jeden Fall noch die Befehle xev, xmodmap -pm und xmodmap -pke merken, denn die werdet ihr sicher für das Unterfangen brauchen.
Mit

xmodmap -pke > .Xmodmap

lässt sich die gesamte Keytabelle in die Datei .Xmodmap schreiben, womit die Einstellungen, in der Theorie, mit Hilfe der .xinitrc wiederhergestellt werden können. Das Verhalten ist leicht wahnsinnig, also nichts für schwache Nerven. 🙂

DWM und Xsetroot

So sieht meine .xinitrc im Moment aus.

#!/bin/sh
if [ -f $HOME/.Xmodmap ]; then
	/usr/bin/xmodmap $HOME/.Xmodmap
fi
#xmodmap -e "keycode 108 = Super_L"
urxvtd -q -o -f&
while xsetroot -name "`date` `uptime | sed 's/.*,//'`"
do
	sleep 20
done &
exec dwm

Der erste Abschnitt liest die Einstellungen aus der .Xmodmap bei jedem Login ein, Zeile 9 startet Urxvt im ressourcensparenden Daemon-Modus und von 11-14 benutze ich eine Funktion, um das Hintergrundfenster von X mit einer Statusanzeige zu versehen. Standardmäßig stellt DWM hier die eigene Versionsnummer dar.
Die Anzeige lässt sich mit dem Befehl Xsetroot verändern. Weitere interessante Beispiele gibt es unter dem Stichwort DWM im ... ArchLinux-Wiki. Ebenfalls bemerkenswert ist die Erweiterung dwmstatus, ein Grundgerüst, mit dem es möglich ist fortgeschrittene Statusanzeigen einzubauen.

Surf und Tabbed

Last but not least, im Zusammenspiel mit surf und tabbed ist DWM erst richtig vollständig. Wo surf unter einem "normalen" Fenstermanager vielleicht suspekt erscheint, spielt er hier seine wahre Stärke aus. Startet zuerst tabbed mit dmenu. Shift+Strg+Enter öffnet Surf direkt in den "Tabs", mit Strg+G geht es zur Adresszeile. URL eintippen und mit Shift+Strg h/l zum nächsten Tab wechseln.

Wie zuvor schon erwähnt, hat der Surf-Backport Probleme bei der Darstellung einiger Https-Seiten, weswegen Midori eine sinnvolle Alternative auf dem älteren Laptop bleibt.
Ich denke zum Thema DWM ist vorerst alles gesagt. Immer dann, wenn ich eine grafische Anwendung brauchen sollte, bietet er ab sofort einen Rückzugspunkt vom Konsolensetup mit Screen. 😉

Einen maßgeschneiderten dwm-Fenstermanager von sid nach squeeze backporten

Obwohl ich denke, dass der Fenstermanager dwm in der Standardkonfiguration schnell zu erlernen und außerdem schlicht und ressourcensparend ist, wollte ich dennoch 2-3 Dinge verändern. Da Veränderungen bei dwm nur durch eine Neukompilierung möglich sind, habe ich die Gelegenheit genutzt und mich wieder etwas mehr mit der Erstellung eigener Debianpakete beschäftigt.
Ich hatte in dem Beitrag "Wie man Debian Pakete aus den Quellen baut" mehrere Methoden vorgestellt, wie man eigene Software speziell für Debian kompilieren kann. Die Pbuilder-Methode gefiel mir davon am besten. Erfolgreich wurde damit ein Mplayer nur für den Framebuffer und auch schon ein paar kleinere Backports erstellt.
Bevor ich meinen Weg zum Kompilieren und Anpassen von dwm vorstelle, wollte ich noch auf eine Alternative hinweisen. Im englischen Forum auf forums.debian.net gibt es schon eine sehr ausführliche Anleitung zum Kompilieren und Konfigurieren von dwm, die den Standardweg mit make und den Debian-Weg mit dpkg-buildpackage zeigt. Wie auch immer, ich denke Pbuilder ist noch einfacher.

Der elegante Weg mit pbuilder

Vorbereitung

aptitude install pbuilder
pbuilder create --distribution squeeze

oder wenn man z.B. i386-Pakete mit seinem AMD64-System bauen möchte

pbuilder create --distribution squeeze --debootstrapopts --arch --debootstrapopts i386

Quellen freischalten

deb-src http://ftp.de.debian.org/debian/ sid main in /etc/apt/sources.list hinzufügen.
Als normaler Benutzer das Quellpaket herunterladen und in das Quellverzeichnis wechseln.

apt-get source dwm
cd dwm-5.9/

Zwei Möglichkeiten

Möglichkeit 1

cp config.def.h config.h
vim config.h

Möglichkeit 2

cp config.def.h debian/local/config.apo.h
vim config.apo.h

Das Debian-Quellpaket bietet zum einen die Möglichkeit die Konfigurationsdatei wie gewohnt im Hauptverzeichnis editieren zu können oder aber im Debian-Verzeichnis. Der Paketverwalter von dwm hat hierzu einige Regeln angepasst, so dass beim Kompilieren auch alle Dateien im Verzeichnis debian/local in der Form config.*.h berücksichtigt werden.
Das hat später den enormen Vorteil, dass man gleichzeitig verschiedene Versionen von dwm übersetzen und später mit Debians update-alternatives Mechanismus auswählen kann.

Konfiguration

Ich habe die zweite Möglichkeit gewählt und die config Datei in debian/local namens config.apo.h modifiziert und folgende Dinge geändert.

  1. Farbe von hellblau auf dunkelgrau ändern
    static const char selbordercolor[] = "#333333";
    static const char selbgcolor[] = "#333333";
  2. Anzahl der Tags von 9 auf 6 verringern
    static const char *tags[] = { "1", "2", "3", "4", "5", "6", };
    
  3. Anstelle der ALT-Taste die Super/Windows-Taste benutzen
    #define MODKEY Mod4Mask
  4. rxvt-unicode anstatt xterm benutzen
    static const char *termcmd[] = { "urxvtc", NULL };

Das war es auch schon. Mir war insbesondere der Wechsel von xterm zu rxvt-unicode und von ALT zu Mod4 wichtig, da es einige Programme gibt, bei denen die voreingestellte ALT-Taste zu Problemen führen kann.

Kompilieren

Das Quellpaket aktualisieren

dpkg-source -b dwm-5.9/

Als Benutzer root ausführen

pbuilder build dwm_5.9-1.dsc
Das fertige I386-Squeeze-Paket fällt in /var/cache/pbuilder/result heraus und muss danach nur noch auf dem Zielrechner mit dpkg -i dwm_5.9-1_i386.deb installiert werden.
Mit dem Befehl update-alternatives --config dwm lässt sich danach zwischen der Standardversion, der dwm.web und der dwm.apo Version umschalten.

Fazit

Ich denke die Pbuilder-Methode sollte man sich aus mehreren Gründen beim Bauen von Debianpaketen merken. Zum einen lässt sich damit in einer "Reinraum-Umgebung" ein Paket sauber kompilieren. Man kann auf einer AMD64-Maschine mit Debian Unstable I386-Pakete für Debian Stable bauen und darüber hinaus sogar mehrere Pbuilder-Umgebungen parallel installieren, in denen Pakete für Testing, Unstable oder auch Ubuntu gebaut werden können!
Beachten sollte man aber, dass dieser Backport noch nicht den offiziellen Ansprüchen genügt. Insbesondere wurde das Paket nicht richtig umbenannt, das Changelog nicht geändert oder persönlich mit GnuPG signiert. Aber für den privaten Hausgebrauch sollte es reichen. 😉
Als optionale Ziele hatte ich mir noch vorgenommen surf, den minimalistischen Webkit-Browser aus der Suckless-Familie, und rxvt-unicode-256color "backzuporten", da es für beide keine Version in Squeeze gibt.
Kurz gesagt: Surf lässt sich genauso einfach von Sid nach Squeeze backporten, er funktioniert auch, es gibt aber einen schweren Bug beim Aufruf von Https-Seiten, der so mit Debian Unstable nicht auftritt. Backports sind also unter Umständen gar nicht so schwierig, man sollte aber immer auch im Hinterkopf behalten, das Probleme nicht nur beim Übersetzen auftreten können. Mehr Details zu rxvt-unicode-256color und dwm demnächst auf diesem Kanal.

Finde den besten WebKit-Browser oder programmiere ihn einfach in 20 Minuten selbst

Ich glaube Linux bietet bei kaum etwas anderem mehr Auswahl und Vielfalt als bei Webbrowsern. Spätestens seit Google das Chromium-Projekt gestartet hat, ist auch dem Letzten die zentrale Bedeutung, das wahre Herzstück, des modernen Desktops ins Bewusstsein gerückt worden. Jeder namhafte Hersteller von Betriebssystemen und Global Superplayer strebt heutzutage die Vorherrschaft im Kampf um den Webbrowser der Zukunft an ...oder lässt nach einem Jahrzehnt zumindest alte Schrecklichkeiten endlich sterben. Vom Browserkrieg war gar schon oft die Rede.
Dabei sollte gerade in Bezug auf Webbrowser weniger das Kriegerische als das Verbindende hervorgehoben werden. Nehmen wir doch als Beispiel mal das WebKit-Projekt. Alles begann einmal als Weiterentwicklung eines anderen Open-Source-Projektes namens KHTML, was noch heute die Grundlage für Konqueror bildet, der wohl bekanntesten Applikation des KDE Desktops. Irgendwann hat dann Apple die Technologie verbessert und als WebKit-Engine zur Grundlage des eigenen Safari-Browsers gemacht. Andere bekannte Größen wie Nokia oder Google sprangen auf den gleichen Zug auf und so entwickelte letzteres Unternehmen schließlich den Chromium-Browser, der sich schnell als dritte Größe zwischen dem Internet Explorer und Firefox etablieren konnte.

Da behaupte noch einer es ginge immer nur gegeneinander. WebKit ist ein Paradebeispiel, warum Open Source und Freie Software so wichtig und auch so erfolgreich sein kann. Irgendwo beginnt eine Idee zu wachsen, ein anderer greift den Gedanken auf und verwirklicht ihn schließlich. Dank des offenen und frei verfügbaren Quellcodes gesellen sich immer weitere Akteure dazu und machen die Idee besser. Man hat ausdrücklich die Möglichkeit voneinander zu lernen und Wissen wird nicht wie in einer mittelalterlichen Gilde im Geheimen verborgen gehalten. Nur so gelingen Innovationen und Fortschritt schneller.

Wähle deinen Browser

Im letzten Post scherzte ich noch, dass rekonq der gefühlt 23. Webkit Browser sei. Ich lag damit gar nicht so falsch! Webkit.org listet auf der eigenen Webseite zumindest 22 auf Webkit basierende Browser auf, wobei rekonq in der Auflistung sogar fehlt. Doch bevor ich damit begann meine übersinnlichen Fähigkeiten zu preisen, fiel mir auf, dass zumindest sowohl xxxterm als auch uzbl in der Liste fehlten und wer weiß wie viele andere noch.
Die Auswahl bei WebKit-Browsern ist also verblüffend groß. Da ich gerne Browser auf älterer Hardware ausprobiere, befinden sich auf meinem Inspiron 4000 neben Iceweasel 5, Chromium 12, Opera 11.5 auch Midori und surf.
Die letzten beiden sind, wie sollte es auch anders sein, ebenfalls WebKit-Browser. Genauer gesagt basieren sie auf WebKit/GTK. Zwar ist der universelle Browser immer noch elinks für mich, aber es mag Zeiten geben, wo ich mir eine Webseite auch mal hübsch gerendert und mit etwas Javascript anschaue. Dabei leistet surf, entwickelt übrigens von suckless, das uns den großartigen Fenstermanager dwm bescherte , auf einer alten Kiste Erstaunliches.


Das ist surf. Nein, hier ist nichts versteckt oder irgendwelche Funktionen deaktiviert worden. Surf stellt nur die Webseite dar und kann auch Links folgen. Keine Werkzeugleisten, Lesezeichen und Addons. Surf konzentriert sich nur auf das Wesentliche - Browsen. Die Darstellung von Webseiten ist dank WebKit hervorragend. Bedienen lässt sich dieser minimalistische Traum mit ein paar Tastenkombinationen. Die in urxvt geöffnete man-Seite zeigt wie es geht. Um zu einer Seite zu gelangen, einfach STRG+g drücken und Adresse eingeben oder surf direkt von der Kommandozeile mit

surf www.meinetolleinternetseite.de

starten. Surf kann keine Tabs, zumindest solange man nicht tabbed installiert hat oder schon die Vorzüge von kachelnden Fenstermanagern wie z.B. dwm oder Awesome kennt. Ich persönlich kann surf einiges abgewinnen.

Oder programmiere ihn selbst

Ich habe mich lange Zeit gefragt, welchen Grund es gibt, dass WebKit-Browser so verbreitet sind. Eine Open-Source-Engine wie WebKit ist eine Sache, aber einen Browser zu programmieren, das stellte ich mir als fortgeschrittene und vor allem zeitintensive Aufgabe vor. Doch dann fand ich dieses geniale 20 minütige Videotutorial zur Programmierung eines WebKit-Browsers mit Python und GTK in Englisch. Danach war mir schlagartig klar, warum es so viele WebKit-Browser gibt. Es macht einfach unheimlich viel Spass einen solchen zu programmieren. Das Tutorial ist aber auch erste Sahne und sehr empfehlenswert. 🙂
Wer sich die Mühe nicht selbst machen will ein paar Zeilen abzutippen, kann auch gleich hinüber zu K.Mandla navigieren und sein 1,5 KB großes Pythonskript kopieren und dann damit anfangen im Netz zu surfen.
Was bleibt als Fazit? WebKit-Browser machen Spass und der IE 6 ist endlich Geschichte. Es darf gefeiert werden.