Porting dcop calls which return a DCOPRef
David Faure
faure at kde.org
Fri Jun 23 09:23:19 BST 2006
On Thursday 22 June 2006 01:26, David Faure wrote:
> On Wednesday 21 June 2006 23:49, Thiago Macieira wrote:
> > David Faure wrote:
> > >Anyway I just realized that in most cases, the DCOPRef being returned is
> > > for an object created in process ... so there is little point in
> > > returning the service name again. If I ask konqueror-123 to create a
> > > window, the service of the window's dbus object will obviously be part
> > > of konqueror-123 too. So I could just s/DCOPRef/QString/ and document
> > > that this is a dbus object path. Does this make sense?
> > >(see kdebase/konqueror/KonquerorIface.h for an example)
> >
> > True. This is exactly the reason why D-BUS has a native type
> > called "Object Path" that you can send and receive over the bus. Prior
> > to "Pattern Buffer" (the new marshalling system), you were not able to
> > place calls directly using "object path" values.
> >
> > Now, all you have to do is send a value of type QDBusObjectPath.
>
> Sounds good. However dbuscpp2xml doesn't like that, and skips all such methods.
Actually I realized that I don't need to use dbuscpp2xml+dbusidl2cpp to convert a
dcop interface (e.g. KonquerorIface) into a dbus adaptor (KonquerorAdaptor).
It's much easier to just edit the file and write the adaptor manually.
The Q_CLASSINFO with the introspection XML is missing then, compared to generated
adaptors, but from reading the qtdbus code, it seems that the XML is generated on the
fly in such a case, so that's fine.
--
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel
mailing list