MAY
31
2006

So long and thanks for all the fish...

With commit 546830, KDE says good-bye to one of its longest friends: DCOP. The technology has served us well for 6 years, to the point that has become one of our most proeminent features. Many KDE applications are given an edge over their competitors by supporting advanced functionality through DCOP: you can tell a Konqueror page to evaluate a JavaScript code snippet (think document.write...), tell a Kate window to raise itself, Kontact to check email or Kopete to send an automated message, etc.

We now say hello to DCOP's younger brother: D-BUS. I merged this morning all the changes I had in a separate branch back into trunk. This completes one phase of the work and starts a new one!

D-BUS brings us better interoperability with many other programs. While DCOP was pretty much restricted to KDE applications (yes, I know there were C bindings, but not many people used it...), D-BUS already comes with bindings for several other major frameworks: glib, Java, Python, Perl, Mono, etc. D-BUS has been designed from the ground up to be an interoperable IPC system and also to replace DCOP when the time came. And so it did.

D-BUS also allows us to better talk to our own system: projects like HAL and Avahi are already being used by many Linux distributions to let normal applications get access to some privileged resources. In time, I also hope the Portland Project to come around and use D-BUS for its IPC needs, thus freeing us from using a special library with its own protocol to do what D-BUS already does.

You may have noticed a pattern in the links above: all are "freedesktop.org". So, yes, KDE is collaborating with the free desktop initiative. But D-BUS isn't restricted to freedesktop.org projects! In case you didn't know, the Nokia 770s use D-BUS extensively for its own internal IPC. There's also the Tapioca Project using D-BUS. Those are just a few: there are many more (and that list is far from complete).

And, of course, KDE now. (We probably bring more applications into D-BUS in one go than there currently are...)

Many thanks to Simon Hausmann, Harald Fernengel, Kévin Ottens, Benjamin Meyer and Roberto Raggi for helping me with the KDE Libs port to D-BUS. And many thanks to Trolltech for letting me develop and maintain the QtDBus bindings.

Comments

How to? I always wanted to be able to start an application or bring its window on top when an instance is already started. Something I never found out how to do (dcop documentation is §$$%"§%$), while window order handling in Windows is quite simple since ages (via pid, application name, window caption,...).


By carlo at Wed, 05/31/2006 - 14:28

dcop kate-$PID __KateMainWindow#1 restore
dcop kate-$PID __KateMainWindow#1 raise

Note that the raising a window to the foreground is subject to the Window Manager's focus stealing prevention mechanism. "raise" will generally just flash on the taskbar, indicating the application wants attention.

To defeat it, you can try as well:
dcop kate-$PID __KateMainWindow#1 hide
dcop kate-$PID __KateMainWindow#1 show


By Thiago Macieira at Wed, 05/31/2006 - 16:03

show doesn't work. raise does indeed cause it only flashing, unless I disable the focus stealing prevention app-/window-wise. Unluckily this funtionality is specific to Kate, but the application I'm interested in is Amarok - still using 1.3.8, maybe a newer one provides such functionality already.

To clarify what I want to achieve: A script that checks, if an amarok instance is running and then (depending on its status) either starts it, raises it or minimizes it to tray. The script should be called by clicking the single media key on my keyboard.

In my eyes this is basic desktop functionality, similiar to iterating through window handles and modifying the window properties on Windows. I really wonder, that this functionality hasn't been made accessible via dcop long ago.

It would be nice, if each app in KDE 4 would expose its window properties (#desktop, position, size, maximize, minimize, opacity, etc.) via dbus.

edit:

Uh, actually it is quite simple, looking up, which options Amarok takes. It's still a pity that there's no consistent window handling with dcop, though.

amarok.sh:

#! /bin/bash

[[ -n $(dcop --user $(whoami) | grep amarok) ]] &>/dev/null
amarok_running=$?

playpause() {
if [[ amarok_running ]] ; then
amarok --play-pause
else
amarok
fi
}

start() {
if [[ amarok_running ]] ; then
amarok --toggle-playlist-window
else
amarok
fi
}

case ${1} in
--start) start ;;
--playpause) playpause ;;
*) kdialog --error "Invalid option \"${1}\"." ;;
esac


By carlo at Sat, 08/12/2006 - 22:52

You can always have a look at all the methods and such with the DCOP browser ( kdcop )...

===============
"With the first link, the chain is forged. The first speech censured, the first thought forbidden, the first freedom denied, chains us all irrevocably."
-- Picard [quoting Judge Aaron Satie]


By andersen_hc at Thu, 06/01/2006 - 04:09

Nice quote :-)


By Thiago Macieira at Thu, 06/01/2006 - 09:14

I did before asking. With that what dcop provides, it doesn't seem to be possible and since I'm not a bit familiar with X11 <-> application interaction I took the chance to ask, before digging a longer while in code and documentation.


By carlo at Sat, 08/12/2006 - 22:01