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
methods?
> 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");
mykopete.doSomething();
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.)
Koos
More information about the kde-core-devel
mailing list