Skip to content

QDS and D-BUS, tieing up loose ends

Sunday, 18 December 2005  |  Krake

Today I reworked the QDS architecture so it doesn't require the application developer to delegate QApplication creation to QDS.

The main reason for this requirement has been the desire to use a KDE service implementation, which needs a KApplication instance.

The new architecture uses an out-of-process approach for implementing the desktop API access with D-BUS being used as the commmunication layer through the Qt3 binding backport I have blogged about the last few days.

The new QDS-Daemon provides the services based on the same desktop wrapper plugins formerly used directly by the QDS library, but the D-BUS approach also opens the door for implemeting the service directly in the respective desktop environment.

Moreover it allows non-Qt applications to access the service as well :)

Currently the only implemented service is the Launcher, i.e. the interface to start the default handler for a file or an URL, with and without specifying the MIME type.

I hope it still compiles Windows and OS X, I had to rename a few functions and haven't had the opportunity to test there yet.

In case you are interested, these three archives contain the current D-BUS + Qt3 bindings (1MB) or just the Qt3 bindings(14KB) and a QDS snapshot(240KB)

You'll need --enable-qt3 when configuring D-BUS

Remember to set LD_LIBRARY_PATH and PATH (for the D-BUS daemon and tools) if necessary

If you have the qds-daemon running and connected to the D-BUS session bus you can use the launcher like this from commandline:

First make sure the daemon has loaded the launcher:

$ dbus-send --print-reply --dest="de.berlios.QDS" /QDS "de.berlios.qds.Factory.InitLauncher"

Then launch a file

$ dbus-send --print-reply --dest="de.berlios.QDS" /QDS/Launcher "de.berlios.qds.Launcher.LaunchFile" string:"/tmp/test.html"

Or an URL

$ bus-send --print-reply --dest="de.berlios.QDS" /QDS/Launcher "de.berlios.qds.Launcher.LaunchURL" string:"http://www.kde.org/"

Comments