Porting dcop calls which return a DCOPRef

[Thiago Macieira]

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.

However, sometimes you're referring to objects in remote applications. For 
instance, you could ask klauncher to create a new kioslave, at which 
point it would return the object path AND service name of the launched 
kioslave. This has been discussed on the D-BUS mailing list and it has 
been suggested that an additional primitive type be added to carry 
service names.

So far, there has been no conclusion to the discussion.

-- 
Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
  thiago.macieira (AT) trolltech.com     Trolltech ASA
    GPG: 0x6EF45358                   |  Sandakerveien 116,
    E067 918B B660 DBD1 105C          |  NO-0402
    966C 33F5 F005 6EF4 5358          |  Oslo, Norway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060621/cceea1a8/attachment.sig>