Kaum wurde KDE SC 4.4.0 (SC steht für Software Compilation, seit ein paar Wochen nennt sich KDE so, weil es doch langsam viele Software aus dem Projekt gibt) und schon stehen für Fedora 12 die Pakete bereit. Natürlich rechnete ich mit Kinderkrankheiten, denn ein KDE 4-Release war noch nie “Produktionsreif” sondern eigentlich immer Beta. Das ist nun mal so, wen das stört, der soll doch testen und helfen, damit sich das ändert.

Auf jeden Fall wurde KDE schlanker, was die Fensterdekoration angeht. Es gibt einen Formfaktor-Umschalter, der bei mir aber zuerst einmal den kwin-Prozess abstürzen liess.  Ein Erlebnis, welches sich unter verschiedensten Umständen wiederholen sollte. Die Intention des Umschalters ist jedoch durchaus klar, denn bei Netbooks kommt ein ganz anderes Prinzip zum tragen als bei Desktops:

Semantischer Desktop (Nepomuk / Strigi)

Beim semantischen Desktop hat es wieder mal eine Änderung im Backend gegeben. Virtuoso speichert nun die indizierten Daten, Tags etc. für Nepomuk. Angeblich viel schneller und stabiler, merke ich davon nichts. Im Gegenteil, der strigi-indexer ist noch nie soviele male abgestürzt wie jetzt. Er kann meine Dateien nicht mal fertig indexieren (und es sind beileibe nicht mehr als 6 GB). Wenn man nur Nepomuk alleine nutzt (z.B. Tags für Dateien, Kontakte u.ä.), sieht man jedoch, wie cool eine semantische Suchapplikation sein kann. Man gibt einen Namen ein und erhält als ersten Vorschlag “Mail senden an …” wenn der Name ein Mail-Kontakt ist (wenn Strigi hier die Mails indiziert hätte würden auch Namen angezeigt, die nicht in den Kontakten gespeichert sind, sondern mit denen wir einfach irgendwann mal in Kontakt waren). Weitere Vorschläge zeigen auch phonetisch ähnliche Suchanfragen in Wikipedia u.v.m. Würde Strigi funktionieren, wäre Nepomuk noch viel mächtiger, also bitte, stabilisiert den Indexier-Mist endlich, Google hat seit vielen Jahren den Desktop-Indexer stabil am laufen!

Krunner (wird mit ALT+F2 gestartet), den man am besten für die Suche oder Programmaufrufe benutzt, wurde an den oberen Bildschirmrand versetzt (was man natürlich weiterhin frei konfigurieren darf, wenn man das nicht mag). Leider bleibt er manchmal aus unersichtlichen Gründen (Nepomuk?) einige Sekunden stehen.

Plasma

Vieles hat sich in Plasma getan. Besonders freuten mich viele kleine und grössere Änderungen, die dem Benutzer viel mehr intuitives Arbeiten ermöglichen. Viele Details entdeckt man erst später, wie die verbesserten Desktopeffekte, da werden zum Beispiel beim Anzeigen aller virtuellen Desktops die jeweiligen geöffneten Fenster auseinandergehalten, denn wozu sonst ist die Übersicht gut, als um offene Programme zu finden? Bis anhin taugte sie eigentlich nur als netter Effekt um Kollegen zu beeindrucken. Solche Beispiele gibt es einige. Der Hammer ist für mich persönlich der Systemabschnitt der Kontrolleiste. Dort kann man nun diverse Plasmoiden reinwursteln, und es ist nicht einmal unansehnlich!

Ich hätte ja nie gedacht, dass eine 4-Tage-Wettervorhersage so wenig Platz braucht und im Systemabschnitt Platz hat. Wenn man mit der Maus darüber fährt, erhältm man den ausführlichen Wetterbericht. Im Bild dazu sieht man auch den neuen Gerätemanager, der nun Automunt beherrscht, sowie vom Benutzer konfigurierbar ist. Wenn ein versierter Benutzer hat, kann er beliebige Befehle automatisch ablaufen lassen, sobald dieser Stick eingesteckt ist, was sehr viele Möglichkeiten eröffnet (automatische Synchronisation beim Einstecken u.v.m.)

Endlich wurde auch die Verknüpfung von Aktivitäten mit virtuellen Desktops in die normale Konfigurationsoberfläche übernommen:

Ein paar der alten Probleme bleiben: Verkleinert man die Aktivitäten, wird das Scrolling wieder sehr zähflüssig. Bei Multi-Monitor-Betrieb mit TwinView noch viel schlimmer. Das Erstellen von 4 Aktivitäten (eine pro virt. Desktop) ist ja kein Problem, aber was passiert, wenn man es rückgängig macht? Die Aktivitäten bleiben bestehen. Hier müssen seit langem Komfortfunktionen geschaffen werden (eine kleine Aktivitätenvorschau, ohne im Plasma-Bereich zähflüssig herumzustraucheln). Denn wenn man die Zuordnung Aktivität/Desktop wieder einschaltet passiert etwas Altbekanntes: Die mühselig eingerichtete Aktivität wird einem anderen Desktop zugeordnet. Auch wenn man herauszoomt und bei der richtigen Aktivität wieder hineinzoomt, hat man früher oder später ein Durcheinander. So wie ich jetzt nach dem Testen: Weil meine zwei Monitore verschiedene Auflösungen haben, kann ich jetzt genausogut .kde/share/config/plasma* löschen, um von vorne anzufangen. Das bringt mich zum letzten Punkt. Kaum ein Release von KDE konnten die meisten Benutzer ihr .kde behalten. Immer wieder kommt man zum Punkt an dem man sagt „Besser ich lösche die Konfiguration sonst gibts wieder Probleme“. Denn es geht mehr Zeit verloren auf der Suche nach einzelnen Problemem als für die Neukonfiguration der KDE-Oberfläche. Nun kommt aber etwas problematisches hinzu: Nepomuk mit Strigi sammelt Daten in Datenbankdateien innerhalb von .kde. Wenn ein unbedarfter Benutzer nun 1 Jahr lang alle seine Dateien taggt und bei einem neuen Release mal wieder das Löschen von .kde vor der Tür steht…man kann sich vorstellen wie das weitergeht. Für Otto Normalbenutzer braucht es Sicherheit, was die Konfiguration anbelangt. Ein Möglichkeit zum XML-Export von Konfigurationen und Nepomuk-Daten vor Releaseses wäre so etwas. Es ist wie immer: Der Ideen hat es genug, aber es kann immer nur ein Bruchteil davon umgesetzt werden.

Fazit

Für einen als offiziell veröffentlichten Release gibt es viel zu viele Abstürze an so vielen Stellen, dass man das Marketing-Team entmündigen und mit 100 Windows-Installationen bestrafen sollte. Als Technologie-Preview zeigt es aber durchaus, wie exzellent KDE 4.4.x sein wird und das der semantische Desktop wirklich kommt und nützlich ist. Ausserdem sieht KDE unverschämt gut aus und viele Funktionen sind selbsterklärender geworden. Es ist schon lange überfällig, dass anstatt neuen Features die Stabilität in den Vordergrund rückt. Aaron Seigo und Co. wären gut beraten, einen Fork für die Feature-geilen Desktop-User zu machen, und einen Stable-Branch nebenbei zu führen. Denn KDE 4 wird sich wohl kaum in Enterprise-Distributionen verbreiten, wenn es erst in einem Jahr absturzfrei läuft. Was die Features anbelangt, wurde das Vorbild OSX schon vor zwei Jahren übertroffen, aber was die Stabilität angeht liegt sogar Windows 95 vorne im Moment (das soll ein Ansporn sein und kein Gejammere).

Zweiter Eindruck

Nachdem ich nun die meisten Verbesserungen gesehen und getestet habe, bin ich schon sehr viel milder gestimmt. Die Abstürze werden seltener, wenn man die Aktivitäten von Anfang an neu aufbaut. Wenn man ihnen dieselben Namen gibt wie den ihnen zugeordneten virtuellen Desktops (was imho eigentlich automatisch geschehen sollte, wenn man die Zuordnung aktiviert), gibt es auch weniger Konfusion in dieser Hinsicht. Wenn auch Nepomuk und Strigi ausgebaut und stabilisiert werden müssen, fühlt sich alles absolut flüssig und unheimlich konsistent an. KDE rockt wieder!

Nachdem sich der Anfangsstress bei meinem neuen Job als Vollblut-Linux-Admin etwas zu legen beginnt, ist wieder mal Zeit für ein paar Experimente: Schon viel zu lange habe ich dieses Thema aufgeschoben, weil ich mir sagte “Sowas brauch’ ich nicht”. Jetzt wo es einmal läuft habe ich mich schnell daran gewöhnt und will gar nicht mehr anders: Dual-Monitor-Betrieb ohne Xinerama-Ärger.
Wie das geht? Erstmal wie üblich: KEINE ATI-Karte kaufen, sondern den Konkurrenten bevorzugen (vielleicht darf ich diese Aussage endlich mal relativieren in einigen Jahren). Der Rest ergibt sich fast von selbst, denn mit nvidia-settings kann man die benötigten Einstellungen machen. Der Nachteil ist, dass man bei jeder X-Session von neuem die Einstellungen machen muss, da sie nicht im .nvidia-settings gespeichert werden. Man könnte auch die X11-Konfiguration speichern, dies funktioniert bei den modernen Distributionen allerdings nicht (das xorg.conf wird immer spartanischer oder existiert gar nicht mehr). Deshalb lässt man sich die X11-Einträge von nvidia-settings anzeigen und ergänzt sie dann selbst im /etc/X11/xorg.conf:

Section "Device"
        Identifier  "Videocard0"
        Driver      "nvidia"
        Option      "NoLogo" "true"
        Option      "TwinView" "on"
        Option      "TwinViewOrientation" "RightOf"
        Option      "MetaModes" "DFP-0: nvidia-auto-select, DFP-1: nvidia-auto-select"
        Option      "Coolbits" "1"
        Option      "RandRRotation" "yes"
        Option      "AddARGBGLXVisuals" "True"
EndSection
Section "Extensions"
        Option      "Composite" "Enable"
EndSection

Auch hier gilt natürlich: Besser selber mit nvidia-settings erstellen anstatt nur kopieren.

KDE4 macht glücklicherweise fast keine Zicken mit dem Dual-Monitor-Betrieb, auch unter erschwerten Bedinungen wie bei mir (zwei verschiedene Auflösungs-Modi). Es muss lediglich eine sogenannte “Aktivität” unter Plasma hinzugefügt werden, welche sich automatisch der Auflösung des zweiten (rechten) Monitors anpasst. Anders als in anderen Betriebssystemen kann nun auch eine zweite Kontrollleiste erstellt werden, welche dem zweiten Monitor dann dieselbe Funktionalität zur Verfügung stellt wie dem “Hauptmonitor”.

Wie konnte ich sowas praktisches nur so lange ignorieren? Naja, im nächsten Artikel stelle ich Euch “multitail” vor, welches ich ebenfalls leider viele Jahre ignoriert habe.

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