# use the 3-argument version of QDBusInterfacePtr. The interface name you can usually obtain by calling "interfaces" on the existing DCOP object (in this case, "dcop kded favicons interfaces").

+

* use the 3-argument version of {{class|QDBusInterfacePtr}}. The interface name you can usually obtain by calling "interfaces" on the existing DCOP object (in this case, "dcop kded favicons interfaces").

−

# the "application id" becomes a "service name" and it should start with "org.kde"

+

* the "application id" becomes a "service name" and it should start with "org.kde"

−

# the "object id" becomes an "object path" and must start with a slash

+

* the "object id" becomes an "object path" and must start with a slash

−

# it's "kded->call", not "kded.call"

+

* it's "kded->call", not "kded.call"

−

# you don't write the function signature: just the function name

+

* you don't write the function signature: just the function name

−

# custom types are not supported (nor ever will be), so you need to convert them to basic types

+

* custom types are not supported (nor ever will be), so you need to convert them to basic types

−

DBUS also supports multiple return values. You will normally not find this kind of construct in DCOP, since it didn't support that functionality. However, this may show up in the form of a struct being returned. In this case, you may want to use the functionality of multiple return arguments. You'll need to use QDBusMessage in this case:

+

D-Bus also supports multiple return values. You will normally not find this kind of construct in DCOP, since it didn't support that functionality. However, this may show up in the form of a struct being returned. In this case, you may want to use the functionality of multiple return arguments. You'll need to use {{class|QDBusMessage}} in this case:

To run the D-Bus daemon, type the command:
% eval `PATH=$DBUSDIR/bin $DBUSDIR/bin/dbus-launch --auto-syntax`

Compiling QtDBus

QtDBus depends on D-Bus.

D-Bus is found using pkg-config, so if you did not install it to a standard path in the previous step, set the PKG_CONFIG_PATH environment variable:
% PKG_CONFIG_PATH=$DBUSDIR/lib/pkgconfig; export PKG_CONFIG_PATH

Tip

you may want to install QtDBUS to $DBUSDIR too.

QtDBus now lives in kdesupport and uses cmake. It also requires you to have Qt 4.1.3 in order to compile (qt-copy has it). To compile it:
% svn co $SVNROOT/trunk/kdesupport
% cd $your_preferred_objdir
% cmake $OLDPWD/kdesupport
% make

Compiling kdelibs

Remember to set PKG_CONFIG_PATH to where you installed D-Bus to ($DBUSDIR/lib/pkgconfig), where you installed QtDBUS and where Qt is installed ($QTDIR/lib). This is necessary because QtDBUS depends on Qt and is found using pkg-config.

To use teambuilder to distribute the build: pass cmake the flags
-DCMAKE_C_COMPILER=/opt/teambuilder2/bin/gcc -DCMAKE_CXX_COMPILER=/opt/teambuilder2/bin/g++

To use icecream to distribute the build: pass cmake the flags
-DCMAKE_C_COMPILER=/opt/icecream/bin/gcc -DCMAKE_CXX_COMPILER=/opt/icecream/bin/g++

Porting existing DCOP code

Usage of DCOPClient

The most direct replacement of DCOPClient are [1] and [2]. The convenience method QDBus::sessionBus() usually replaces all occurrences of KApplication::dcopClient().

The methods in DCOPClient that are related to listing existing applications on the bus are in QDBusBusService (which you can access with QDBus::sessionBus().busService()).

Hand-written calls using DCOPClient

DCOPClient has a "call" method that takes two QByteArray's containing the data to be transmitted and the data that was received. The most direct replacement for this is using QDBusMessage and QDBusConnection::send or sendWithReply. You most likely don't want to use that.

Calls using DCOPRef and DCOPReply

QDBusInterface is not "cheap": it constructs an entire QObject. So, if you can, store the value somewhere for later reuse.

QDBusReply is a template class, so you must know ahead of time what your reply type is.

If you create a QDBusInterface without specifying the third argument (the interface name), this will generate a round-trip to the remote application and will allocate non-shared memory. So, wherever possible, use the interface name to make it cached.

use the 3-argument version of QDBusInterfacePtr. The interface name you can usually obtain by calling "interfaces" on the existing DCOP object (in this case, "dcop kded favicons interfaces").

the "application id" becomes a "service name" and it should start with "org.kde"

the "object id" becomes an "object path" and must start with a slash

it's "kded->call", not "kded.call"

you don't write the function signature: just the function name

custom types are not supported (nor ever will be), so you need to convert them to basic types

D-Bus also supports multiple return values. You will normally not find this kind of construct in DCOP, since it didn't support that functionality. However, this may show up in the form of a struct being returned. In this case, you may want to use the functionality of multiple return arguments. You'll need to use QDBusMessage in this case:

Normally, "<object-path>" will be the argument the class was passing to the DCOPObject constructor. Don't forget the leading slash. Another useful option to the third argument is QDBusConnection::ExportProperties, which will export the scriptable properties.

Signals

DCOP had a broken support for signals. They were public methods, while normal signals in QObject are protected methods. The correct way to port is to refactor the code to support signals correctly.

On the current version of QtDBus, you cannot use QDBusConnection::ExportSignals. This is a known limitation and will be fixed in the future. In order to use signals, you'll need to write an adaptor.

Adaptors are a special QObject that you attach to your normal QObject and whose sole purpose is to relay things to and from the bus. You'll generally use it to export more than one interface or when you need to translate the call arguments in any way.

MyAdaptor is not exported. This is a private class and the .h file should be a _p.h as well.

There's no need to mark the signals Q_SCRIPTABLE. The same goes for slots and properties.

The "setAutoRelaySignals" function just connects all signals in "parent" to the signals of the same name and arguments in the adaptor.

There's no need to store the adaptor pointer, it'll be deleted automatically when needed. Therefore, do not delete it and, especially, do NOT reparent it.

You can create more adaptors later, if you need. There's no need to re-register the object.

DCOP Transactions

DCOP had the capability of doing transactions: that is, delay the reply from a called method until later on. QtDBus has the same functionality, under a different name.

Unlike DCOP, with QtDBus, you need a special parameter to your slot in order to receive the information about the call and set up the delayed reply. This parameter is of type "QDBusMessage" and must appear after the last input parameter. You declare that you want a delayed reply by creating a reply. You will be responsible for sending it later.