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

[Thiago Macieira]

Em Quarta-feira 05 Agosto 2009, às 10:25:12, David Jarvie escreveu:
> On Wed, August 5, 2009 7:31 am, Thiago Macieira wrote:
> > David Jarvie wrote:
> >>There has been some discussion on the kde-pim list about how to
> >> successfully call D-Bus methods immediately after starting an
> >> application. The problem is that initially, only the D-Bus service for
> >> the application exists, and it is necessary to wait until first its
> >> interfaces and then its methods are ready to be used. Unfortunately
> >> there seems to be no clean way to know when the D-Bus methods are ready
> >> to be called.
> >>
> >>As pointed out by Ingo Klöcker, this is likely to be a problem
> >> encountered by others, so I'm forwarding the discussion to core-devel.
> >
> > The solution is simple:
> >
> > Don't register the service name until your objects are set up. Or, at the
> > latest, make sure that they will be created before the next event loop
> > run.
> >
> > That's Thomas's solution. It's the correct way to go.
>
> If my understanding is correct, KApplication automatically registers a
> D-Bus service for the application in its constructor.

That's to indicate that the KApplication and standard interfaces are ready to 
use. If you have further objects, you may need further names.

Also note that incoming calls are only handled at the next event loop run. So 
any objects created and registered before the event loop gets a chance to run 
(i.e., before app.exec() in main) are also taken into account.

I think this should be plenty.

If you need to add objects after the event loop has started, you may need more 
names. Alternatively, we can make KApplication not register at startup, but 
instead provide a method to register once your app's setup is complete.

Note that delaying the registration of KUniqueApplication introduces a larger 
chance for race condition (the app being started twice, only one instance 
wins). This feature should be used with care.

> Following your
> advice, that would imply that applications can't use their default D-Bus
> service for a callable interface, but must instead set up an additional
> service which they would register later. That might be practical for
> objects/methods which the application explicitly creates, but what about
> default ones like com.trolltech.Qt.QWidget?

That's an interface, not an object path. Please don't mix the concepts.

Read above: the default name is plenty usable, provided you register the 
object before app.exec().

Also you must ensure that nothing in your startup sequence runs a nested event 
loop, like QMessageBox, KIO::NetAccess, D-Bus calls with BlockWithGui, etc.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Software
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- 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/b5076433/attachment.sig>