How to know when D-Bus interfaces and methods are available

Kevin Krammer kevin.krammer at gmx.at
Wed Aug 5 16:40:59 BST 2009


On Wednesday, 2009-08-05, Thiago Macieira wrote:
> Em Quarta-feira 05 Agosto 2009, às 10:09:40, Kevin Krammer escreveu:
> > How about creating a QDBusInterface without specifying an object path and
> > let the adapter emit a signal with the object path. Then creating a
> > QDBusInterface for that specific object.
>
> You can't create a QDBusInterface without object path. QDBusInterface
> requires a running and existing object when it's created so that it may
> introspect.
>
> You must use an interface generated by qdbusxml2cpp to use it without
> object paths. You can also use it without service names. This kind of
> interface cannot be used for calling, but it can be used to connecting to
> signals.

Ah, good to know.
I guess it does that through QDBusConnection::connect()?
Was there a specific reason why QDBusInterface was limited to introspectable 
objects?

> So your object could emit a signal when it's ready to be used. The target
> application would then receive it and create the QDBusAbstractInterface
> with service and object path.

Right, or create the generate object. Main point is that the caller 
application would listen for a given signal which would indicate that some 
object now has that interface available.

A bit like connting to nameOwnerChanged but a lot more precise.

> If you already know the service and object path though, you can use
> QDBusAbstractInterface directly, even if the object doesn't exist yet. You
> just have to be careful about making calls.

Also a good tip!

Cheers,
Kevin
-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090805/eeef1fdc/attachment.sig>


More information about the kde-core-devel mailing list