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.
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/"