Qt-DBUS (was: KDE4's IPC)

[Thiago Macieira]

Waldo Bastian wrote:
>> The problem I'm facing now is how to define which methods will be
>> exposed through the DBUS channel.
>
>Qt's meta model has a QMetaMethod::Scriptable qualifier that controls
> whether the method is exposed. I haven't figured out how it works, I
> guess there is some keyword that you can add and that is recognized by
> moc.

Yeah, that's the same conclusion I came up with. Apparently, we can use 
the Q_SCRIPTABLE tag somewhere in the declaration, which would provide us 
with a detectable tag in QMetaMethod.

Another possibility is to expose all signals and slots defined by that 
class (but not its ancestors).

I'd probably go with option #1, which in turn leads me to the conclusion 
that the parser for the .h is moc itself. That's one less parser to run!

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.

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");

The way I see it, the best way would be if moc itself generated the XML 
introspection output. I have no idea if Trolltech will allow us to modify 
it for that purposes -- maybe through a moc plugin -- but it's worth the 
try. The reason for that is the bindings use the information generated by 
moc, so we should avoid if possible re-parsing the file and ending up 
with conflicting information.

>> First of all, I don't see how to set multiple interfaces in the same
>> object so that they appear to have different methods externally.
>>
>> Second, I don't see a way of specifying which slots can be called
>> externally. The bindings allow any slot to be called.
>>
>> Third, the bindings don't have yet any way of listing the available
>> methods in an interface. I think all the information we need is
>> already collected by moc (properties, signals and slots), so it would
>> be possible to handle that at the binding level and generate the
>> introspection format on the fly.
>
>Yes, that's the first thing on the Qt-DBUS todo list I think.

See above. I think we can easily solve #2 and #3, but I still don't see a 
way out for #1 without multiple-inheritance or doing it manually.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

5. Swa he géanhwearf tó timbran, and hwonne he cóm, lá! Unix cwæð "Hello, 
World". Ǽfre ǽghwilc wæs glæd and seo woruld wæs fréo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20051225/230a445b/attachment.sig>