"Christmas - the time to fix the computers of your loved ones" « Lord Wyrm

DCOP - Was KDE unter der Haube hat, Pt. 1

COLOSSUS 06.09.2006 - 21:47 2365 7 Thread rating
Posts

COLOSSUS

Administrator
GNUltra
Avatar
Registered: Dec 2000
Location: ~
Posts: 12067
KDE, das unter der GNU General Public License stehende, freie K Desktop Environment, hat eine Menge Fans - der eine wohl mindestens ebensogrosze Anzahl Gegner gegenuebersteht, die meinen, es waere ein Windows-Abklatsch, oder generell ein klobiges Stueck Software, dessen Einsatz auf einem X11-faehigen, unixoiden System - zum Beispiel GNU/Linux - sich nicht lohnt. Mit diesem kleinen Tutorial will ich nicht nur ein wenig auf die elegant gestalteten Interna von KDE eingehen, sondern auch eine wirklich nuetzliche Anwendungsmoeglichkeit eines der wesentlichen Bestandteile dieses Desktops aufzeigen: die von DCOP naemlich, dem Desktop Communication Protocol.

Auch wenn DCOP mit Release 4 von KDE, dessen erstes Technolgy Preview kuerzlich der staunenden Oeffentlichkeit praesentiert wurde, vom generischen, durch die freedesktop.org-Initiative standardisierten DBUS abgeloest wird, lohnt es sich doch auf jeden Fall, es mehr als eines Blickes zu wuerdigen - und das nicht nur, weil KDE 3.5 noch einige Zeit das Flaggschiff des KDE-Projekts bleiben wird.

DCOP ist ein applikationsuebergreifendes Kommunikationssystem, mit dem Programme Nachrichten untereinander austauschen koennen. Diese Nachrichten werden ueber den DCOP-Server - fuer jeden User, der eine KDE-Session laufen hat, ist ein solcher gestartet - zum Empfaenger geroutet, und von diesem entsprechend geparsed (ausgewertet).

Dieses System kann ueber viele verschiedene Wege genutzt werden - es existieren Bindings fuer einige weitverbreitete Programmiersprachen, darunter natuerlich C++ (die Sprache, in der KDE und das darunterliegende Qt-Toolkit von Trolltech implementiert sind), oder auch die wunderschoene Skriptsprache Ruby.
Aber, und das soll uns hier vordergruendig von Interesse sein, DCOP laesst sich auch ueber ein fuer UNIX-typisches Kommandozeilen-Tool, das den gar nicht zu kryptischen Namen `dcop` traegt, nutzen - und das durchaus clever, wie ich hoffentlich noch zeigen werde koennen.

Am besten, wir halten uns gar nicht zu sehr mit einer hochtechnischen Beschreibung auf, sondern stuerzen uns mitten ins Vergnuegen... In einer ordnungsgemaesz gestarteten KDE-Session starten wir einen Terminal-Emulator (z. B. Konsole, das zu KDE gehoert), mit der Shell unserer Wahl (in meinem Fall `bash` aus dem GNU-Projekt) in ihm. Um zu sehen, ob ein DCOP-Server laeuft, bedienen wir uns des Programmaufrufs `ps -ef | fgrep dcop`. Das liefert einen Output aehnlich dem Folgenden:

Code:
colo@zealot ~ $ ps -ef | grep dcop
colo      8542     1  0 Sep03 ?        00:00:26 dcopserver [kdeinit] --nosid
colo      7546  7535  0 20:52 pts/11   00:00:00 grep --colour=auto dcop

(Anm.: Die letzte Zeile beinhaltet hier auch den Aufruf von `grep`, der sich prinzipbedingt immer in dieser Art Kommando-Pipekonstrukt wiederfindet. Will man tatsaechlich nur die PIDs der Programme eruieren, die "dcop" in ihrer Aufrufsbefehlszeile beinhalten, verwendet man besser `pgrep`. Die entsprechende Manpage verraet hierzu mehr.)

Nachdem offenbar ein DCOP-Server am System laeuft (der Name des Prozesses mit der PID 8542, "dcopserver", laesst darauf hoffen ;)), versuchen wir eine erste, zaghafte Kontaktaufnahme durch den schlichten Aufruf von `dcop`:

Code:
colo@zealot ~ $ dcop
konsole-7534
kwin
kicker
konversation
 [b][ ... tatsaechlicher Output gekuerzt ... ][/b]
kopete
kwalletmanager
kgpg
akregator

(Anm.: Sollte dcop mit einer Fehlermeldung reagieren, dass es nicht wuesste, mit welchem DCOP-Server es kommunizieren solle, hilft der Ersatz aller Aufrufe von `dcop` jetzt und im Folgenden durch `dcop --user $USER`. Dies sollte im Normalfall aber eigentlich nicht noetig sein. Durch den Parameter "--user" ist es zusaetzlich auch moeglich, mit den DCOP-Servern anderer am System eine KDE-Session laufen habende Benutzer zuzugreifen, sofern diese das erlauben und/oder erwuenschen.)

Diese Liste von laufenden Applikationen verraet uns, welche Programme denn nun alle in freudiger Erwartung auf Nachrichten ueber das DCOP-System warten. Die weitere Bedienung ist ziemlich selbsterklaerend - wollen wir z. B. feststellen, welche Operationen wir ueber DCOP auf dem Instant Messenger Kopete durchfuehren koennen, reicht das Ausfuehren von `dcop kopete`, was auf meinem System diesen Output zur Folge hat:

Code:
colo@zealot ~ $ dcop kopete
qt
0x8446518
KIMIface
KIO::Observer
KIO::Scheduler
KopeteChatWindow
KopeteIface (default)
MainApplication-Interface
ManagerIface_contact
html-widget113
html-widget195
kopete
kopete-mainwindow#1
kopete-mainwindow#2
ksycoca
mainWindow

Nicht alle retournierten Strings sind hier fuer uns von momentanem Interesse; wir wollen uns auf die "KopeteIface"-Facility beschraenken, die zwar Kopete-spezifisch (einige Facilities, wie zum Beispiel "MainApplication-Interface", finden sich in allen DCOP-faehigen Programmen - andere wiederum nicht), zugleich aber auch wirklich interessant und nuetzlich ist.
Wagen wir uns also noch eine Veraestelung weiter in den DCOP-Baum, durch Ausfuehren von `dcop kopete KopeteIface`. Uns erwartet (in meinem Fall, andere Builds von Kopete weisen evtl. enstsprechend mehr oder weniger Funktionen auf!) folgende Ausgabe:

Code:
colo@zealot ~ $ dcop kopete KopeteIface
QCStringList interfaces()
QCStringList functions()
QStringList contacts()
QStringList reachableContacts()
QStringList onlineContacts()
QStringList fileTransferContacts()
QStringList contactFileProtocols(QString displayName)
QStringList contactsStatus()
QString messageContact(QString contactId,QString messageText)
QString onlineStatus(QString metaContactId)
void messageContactById(QString metaContactId)
bool addContact(QString protocolName [...] QString groupName)
QStringList accounts()
void connect(QString protocolName,QString accountId)
void disconnect(QString protocolName,QString accountId)
void connectAll()
void disconnectAll()
bool loadPlugin(QString name)
bool unloadPlugin(QString name)
void setAway()
void setAway(QString msg)
void setAway(QString msg,bool away)
void setAvailable()
void setAutoAway()
void setGlobalNickname(QString nickname)
void setGlobalPhoto(KURL photoUrl)

Hier wird es noch ein Stueck interessanter: Wer schon einmal (in einer "strongly-typed"-Sprache zumindest ;)) programmiert hat, dem werden als jeweils erstes Wort pro Zeile die verschiedenen Rueckgabewerte der Funktionen auffallen - und in Klammern notiert die von den Funktionen erwarteten Parameter, falls notwendig. Die meisten dieser Funktionen sind ziemlich selbsterklaerend, weil sprechend bezeichnet. So gibt z. B. `dcop kopete KopeteIface onlineContacts` (die Klammern fuer die Funktionsparameter koennen hier ohne Weiteres entfallen) eine Liste aller sich momentan online befindenen Kontakte aller meiner IM-Accounts aus, waehrend `dcop kopete KopeteIface disconnectAll` die Verbindungen zu allen IM-Netzwerken, die zur Zeit bestehen, trennt. Durch Kombination mit einigen Standard-GNU-Tools kann man hier ohne viel Aufwand sehr nette Sachen skripten, die sich auch zeitgesteuert via `cron` oder X11-losen SSH-Login durchfuehren lassen. Will ich zum Beispiel wissen, ob der User mit dem Nickname "foobar@jabber.org" gerade Online ist, so reicht ein Absetzen von `dcop kopete KopeteIface onlineContacts | fgrep protected` - den Bruchteil einer Sekunde spaeter kann ich mir sicher sein.

Dies ist natuerlich nur ein rudimentaeres Beispiel, da andere DCOP-Funktionen noch viel mehr koennen - z. B. im Falle von Kopete geskriptet Nachrichten an bestimmte User verschicken, bei dem freien Audioplayer Amarok diverse Playlistfunktionen initiieren oder die Metadaten (Tags) des gerade gespielten Tracks ausgeben, oder die Wallpaper von `kdesktop` (Teil von kde-base) neu setzten - mit ein bisschen Kreativitaet kann man alles das ueber die Kommandozeile erreichen, was sonst ueber die GUI dieser KDE-Programme zu tun pflegt.

Wer DCOP lieber graphisch erkundet, dem sei das Programm `kdcop` an's Herz gelegt, welches der Standarddistribution von KDE beiliegt. Es eignet sich schoen, um ein wenig mit den Funktionen von DCOP zu spielen und diese zu erkunden; zum Skripten bietet sich aber natuerlich eher der CLI-DCOP-Client an.

Alsdenn, ich hoffe, dieser kleine Einstieg in die durchaus interessante Materie DCOP hat euch gefallen, und wird sich fuer den einen oder anderen User als tatsaechlich nuetzlich erweisen. Viel Vergnuegen auch weiterhin mit dem tollen KDE-Desktop!
Falls ihr diesen nicht nutzt, oder noch gar nicht probiert habt - Mit der SLAX-LiveCD - oder aber auch Knoppix - laesst er sich ganz ohne Risiko testen. Es lohnt sich, glaubt mir ;)

Dieses Tutorial ist unter den Bedingungen der GNU Free Document License verbreitbar. ©2006 Johannes Truschnigg
Bearbeitet von COLOSSUS am 04.10.2006, 00:21 (Typo fixed.)

COLOSSUS

Administrator
GNUltra
Avatar
Registered: Dec 2000
Location: ~
Posts: 12067
Hoe... MASSIV falsches Forum, wtf?! Bitte in's GNU/Linux- UNIX und *BSD-Forum verschieben :D

E: Danke fuer die Kooperation :)

derelict

Legend
Legend
Avatar
Registered: May 2004
Location: outside
Posts: 365
#!/bin/sh
dcop kmix Mixer0 setMute 3 $(expr $(dcop kmix Mixer0 mute 3) = false)


Toggelt einen Channel (in dem Fall 3 -> dort hängen die Lautsprecher) auf mute ... praktisch wenn man nur einen Channel muten will und nicht alle.

Das auf einen Hotkey binden ... feddich.

Marcellus

OC Addicted
Avatar
Registered: Mar 2005
Location: ~
Posts: 1755
Und wieso genau sollte man jetzt kde verwenden? Ich mein, ja es kann mehrerer grafische prozesse verwalten, es hat eine startleiste, mit der man programme starten kann, aber was genau kann kde, was wmii, fluxbox, xfce, enlightment, wii oder wwi nicht können?

Ich mein das beispiel ist recht nett, aber ich bin mir sicher, dass man mit minimalen änderungen am kopete source durchaus auch alles realisieren kann, was man überhaupt mit dem programm erreichen kann.

@derelict
Ich hab mehr oder weniger das gleiche programm für amixer geschrieben und mit xbindkeys eingebunden, ist nicht viel aufwendiger.

Ich mein ich kann schon verstehen, dass eine hand voll recht nette software mitgeliefert wird, aber diese kde libs sind so verdammt speicherlastig.

Ich will jetzt nicht irgendwie über kde herziehen, aber ich wüsste gerne, was euch dazu bewogen hat ausgerechnet kde zu verwenden

COLOSSUS

Administrator
GNUltra
Avatar
Registered: Dec 2000
Location: ~
Posts: 12067
Vielleicht oeffnen dir ja die weiteren geplanten Teile dieser Mini-Serie die Augen.

Bis dahin: Urteile nicht ueber etwas, das du nicht im Ansatz kennst oder gar verstehst.

Marcellus

OC Addicted
Avatar
Registered: Mar 2005
Location: ~
Posts: 1755
Zitat
Ich will jetzt nicht irgendwie über kde herziehen, aber ich wüsste gerne, was euch dazu bewogen hat ausgerechnet kde zu verwenden

...

jives

And the science gets done
Avatar
Registered: Sep 2001
Location: Baden
Posts: 3548
Ich bin zwar XFCE-User, aber solche Artikel sind immer wieder interessant zu lesen. Tolle Arbeit COLO.

*****

Marcellus

OC Addicted
Avatar
Registered: Mar 2005
Location: ~
Posts: 1755
Falls das jetzt falsch rübergekommen sein sollte, ich hatte in keinster weise vor deine arbeit runterzumachen, falls das so rübergekommen ist will ich mich echt dafür entschuldigen, nimms mir plz nicht übel
Kontakt | Unser Forum | Über overclockers.at | Impressum | Datenschutz