Porting dcop calls which return a DCOPRef

[David Faure]

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).