Qt-DBUS (was: KDE4's IPC)

Koos Vriezen koos.vriezen at xs4all.nl
Sun Dec 25 12:49:13 GMT 2005

Thiago Macieira wrote:
> I've been running through my mind how we can accomplish the next steps, 
> after the header parsing:
> 1) the stub
>  - not necessary, since the Qt-DBUS bindings inspect the meta object 
> directly. We should probably just adapt it to detect the Q_SCRIPTABLE 
> tag, instead of exposing all available slots and signals.

You mean that some app having public dbus objects, installs this in
KDEDIE/include and users simply include it, create an object and call it

> 2) the XML introspection
> - we could generate it from QMetaObject on-the-fly (i.e., upon call to the 
> org.freedesktop.DBus.Introspectable interface), but we may also want to 
> install the .xml file for other language bindings.
> 3) the skel
> - hardest part, I'd write it in XSL with a text output by parsing the XML  
> introspection data. The XSL could also be re-used by a command-line 
> utility like 'dcop' to list the methods in a familiar way.
> - I'd like the skels to be fully inlined classes, fully namespaced and all 
> you'd need to do is:
> #include <qdbus/org/kde/KIMProxy>
> using namespace QDBus;
> org::kde::KIMProxy obj(QDBusConnection(), "org.kde.Kopete",
>                                 "/org/kde/kimproxy");
> Or:
> org::kde::KIMProxy obj = connection.findObject("org.kde.Kopete",
>                         "/org/kde/kimproxy");

I don't get this, your doing stub stuff. And that IMO would look much
nicer as described earlier:

 #include <kde-dbus/kopete>
 KopeteStub mykopete ("org.kde.Kopete", "/org/kde/kimproxy");

Does take the default connection, so maybe have a second ctor for that.

I do understand that this only works for remote objects having such a
.h/idl file and that with signal/slots it's not really necessary.
However it does look much more c++ and catches parameter types mismatches
at compile time. Does need a _stub.cpp of course.

(For skel, now we simply declare a class based on DCOPObject and simply
 implement it like a normal class. Would be very nice to more or less keep
 this like that.)


More information about the kde-core-devel mailing list