Linux @ Home

Shellskripte müssen nicht zwangsläufig an die Shell in der Konsole gebunden sein. Sie können auch ansprechend verpackt werden für Otto Normaluser. Dazu gibt es verschiedenste Ansätze. Einer der modernsten und flexibelsten ist kdialog unter KDE4. Das Besondere an kdialog ist seine Fähigkeit zur Interprozess-Kommunikation (IPC) via DBus. DBus wurde von freedesktop.org entwickelt und ist mittlerweile bei fast allen Distributionen standardmäßig vorhanden. In KDE 3 kam dafür das KDE-eigene DCOP zum Einsatz. Noch früher in KDE 1 wurde eine Corba-Implementiereung verwendet. Beide Lösungen waren jedoch zu gross und umständlich.

Mein Beispielskript hier zeigt, wie man einen Fortschrittsbalken implementiert, welcher via DBus vom laufenden Shellskript gesteuert werden kann. Natürlich kann man via DBus noch viele weitere mehr oder weniger nützliche oder witzige Dinge machen mit dem jeweiligen Dialog, wie z.B. den Titel und Inhalt laufend verändern etc.

Solche Skripte müssen übrigens nicht auf KDE beschränkt sein. Es sollte schon mittels installierten kdelibs und natürlich kdialog möglich sein, dieselben unter Gnome, XFCE etc.laufen zu lassen, obwohl dort der Einsatz von zenity (GTK-basiert) eher angebracht wäre. Zenity ist praktisch in jeder Distribution installiert. Nur Leider fehlt dort der Progress-Callback resp. die Interprozess-Kommunikation. Zenity’s Progressbar ist dadurch eher eine simple Aktivitätsanzeige. Allen Alternativen zu kdialog ist gemein, dass sie die erwähnte Progressbar lediglich indirekt implementieren, z.B. indem sie die Prozentwerte des Balkens entgegennehmen oder die Aktivität während einer Operation anzeigen, Beispiel:

find /usr/bin | zenity --progress --pulsate

Durch die Verwendung von DBus können wir vielleicht bald auf eine wirklich Desktopunabhängige Lösung hoffen, indem z.B. auch zenity die Dialoge über DBus ansteuerbar macht…

Natürlich halten damit auch wieder die sleep-Anweisungen Einzug, damit nicht alle Text vorbeihuschen. Sie verlangsamen den Ablauf zwar insgesamt, aber bei einem Prozedur wie “USB-Stick entschlüsseln und einhängen” ist dies meines erachtens vernachläßigbar zu gunsten der Lesbarkeit der Infotexte.

#!/usr/bin/env bash
 
# TODO: Dieses Skript sollte durch das udev-System aufgerufen werden
# siehe dazu /etc/udev/rules.d/90-crypto-usb-stick.rules
 
USER=myuser
DEVICE=/dev/usbstick
MAPPERDIR=/dev/mapper/crypto_usbstick
MOUNTDIR=/media/crypto_usbstick
 
dbusRef=$(kdialog --title "Crypto-USB-Stick aktivieren und einhängen" --progressbar "Starte..." 2)
sleep 1
 
if ! kdialog --password "Bitte Passwort für Crypto-USB-Stick eingeben:" | cryptsetup luksOpen $DEVICE ${MAPNAME}; then
    kdialog --error "Konnte das Cryptodevice nicht erstellen! Vermutlich falsches Passwort eingeben?"
    qdbus $dbusRef org.kde.kdialog.ProgressDialog.close
    exit 1
fi
sleep 1
 
qdbus $dbusRef org.kde.kdialog.ProgressDialog.setLabelText "Verzeichnis $MOUNTDIR wird gesucht"
if [ ! -e $MOUNTDIR ]; then
    qdbus $dbusRef org.kde.kdialog.ProgressDialog.setLabelText "Verzeichnis $MOUNTDIR wird erstellt"
    mkdir $MOUNTDIR
fi
qdbus $dbusRef Set org.kde.kdialog.ProgressDialog value 1
sleep 1
 
qdbus $dbusRef org.kde.kdialog.ProgressDialog.setLabelText "Cryptodevice wird nach $MOUNTDIR eingehängt"
if ! mount $MAPPERDIR $MOUNTDIR -orw,user,exec,uid=$USER,gid=$USER; then
    kdialog --error "Konnte den Crypto-USB-Stick nicht in $MOUNTDIR einhängen!"
    qdbus $dbusRef org.kde.kdialog.ProgressDialog.close
    exit 1
fi
sleep 1
 
qdbus $dbusRef Set org.kde.kdialog.ProgressDialog value 2
qdbus $dbusRef org.kde.kdialog.ProgressDialog.setLabelText "Vorgang erfolgreich beendet!"
sleep 2
 
qdbus $dbusRef org.kde.kdialog.ProgressDialog.close

Das Warten auf Fedora 10 hat sich mal wieder definitiv gelohnt! Ich komme trotz vorhandener ATI und Intel-Grafikkarten zwar noch nicht in den Genuss des besten grafischen Schmankerls: KMS (Kernel Mode Setting), aber der Rest scheint auf Anhieb zu klappen wie versprcchen. Es sieht aus wie aus einem Guss, der Bootprozess ist etwas schneller geworden und für mich als KDE-Fan wartet endlich ein einigermassen stabiles KDE 4.1 auf Arbeit. Pulseaudio ist stabiler geworden (wenn auch noch nicht bugfrei) und übernimmt nun alle Audio-Aufgaben, so hat Amarok z.B. gar keine Optionen mehr um die Ausgabe auf etwas anderes umzustellen und das ist gut so.

Hier ein kleiner Status meiner Installationen:

• iMac hat denselben Status (d.h. Mikro und Mausrädchen funktionieren noch nicht)
• Thinkpad: Bis auf die Thinkpad-Buttons (unter KDE4 noch nicht direkt unterstützt) alles o.k. Was mich absolut positiv überrascht und besonders freut: KDE4 scheint sogar mit eingeschalteten Desktop-Effekten genausowenig Strom zu verbrauchen wie KDE3! Im Leerlauf zwischen 11-13 Watt und mit Fensterbewegung (3D und transparent) maximal 16 Watt. Damit scheint KDE4 absolut Netbooktauglich zu sein.

Probleme

Natürlich gibt es auch bei diesem Release ein paar “Wie hat das bloss die Beta-Phase überstanden?” Erlebnisse:

• kpackagekit frisst unersättlich Memory, wenn keine Netzwerkverbindung besteht (Notebook)
• amarok 2.0 ist was die Oberfläche anbelangt noch im Betastadium und die Bedienung alles andere als intuitiv. Ausserdem werden Benutzer, die den “alten” Amarok geschätzt haben, verschreckt mit solchen krassen Oberflächen- und Backend-Änderungen
• Instabilitäten im Zusammenhang mit Xorg und KDE4 mit Dekstopeffekten. Beispiele: Abstürze (selten). Switching auf Konsole und zurück auf KDE (tty1) nicht möglich mit aktivierten Effekten (zumindest mit Intel-Grafikchip).
• xine läuft ca. 1 Sekunde bevor’s einen Speicherzugriffsfehler gibt

Nachtrag:

Nach längerer Testzeit sind mir doch noch ein paar mehr Dinge aufgefallen, vor allem solche, die eigentlich niemals so durch die Finger der Betatester rutschen sollten (ich vermute mal überhastete Updates vor dem Release?). Die Fehler betreffen die KDE-Version, über die Gnome-Version kann ich nichts sagen, da ich sie nicht benutze, aber wie ich Gnome kenne, läuft da alles stabil

• CD’s werden standardmäßig mit kscd wiedergegeben, nur leider ohne Ton! Lösung: Kaffeine benutzen In der Konfiguration das Ausgabegerät auf Phonon stellen (das sollte Standard sein, ist es aber leider nicht)
  
• Auch das Ripping-Programm (Sound Juicer) hat ‘ne Macke: Als wir eine CD der Freundin rippen wollten (frustriert durch obiges CD-Abspiel-Problem), sah ich, dass das Programm *.oga Dateien erstellte. “Na klar, Ogg Audio” dachte ich. Nur schade, dass Amarok dieses Format nicht erkennt beim Scannen der Sammlungs-Ordner! Lösung: Umbenennen nach *.ogg und Amarok erkennt die Stücke wie gehabt.

Fazit

Auf dem Notebook sollte man die Desktopeffekte nur anschalten, wenn man seine Freunde und Kollegen beeindrucken möchte. Danach sollte man vorerst darauf verzichten, weil man sonst im Gegenzug auf Funktionen wie Konsolen-Switch, Suspend-To-Ram und Suspend-To-Disk (resp. das Aufwachen macht Probleme) verzichten muss.
Sonst gibt es eigentlich nichts zu beachten, viel Spass beim Installieren und ausprobieren!