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

[David Jarvie]

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.

On Tuesday 04 August 2009 18:55:30 Thomas McGuire wrote:
> On Tuesday 04 August 2009 02:55:35 David Jarvie wrote:
> > On Sunday 02 August 2009 16:56:46 Volker Krause wrote:
> > > On Sunday 02 August 2009 13:30:31 David Jarvie wrote:
> > > > Can anybody help resolve this D-Bus problem with KMail?
> > > >
> > > > KAlarm has functions to invoke KMail and issue a D-Bus call to show a
> > > > mail. The problem is that if KMail isn't already running, the D-Bus
> > > > call doesn't work when called immediately after starting up KMail,
> > > > since the relevant D-Bus interface is not immediately available. I've
> > > > experimented with various tweaks, and compared the code to other
> > > > places in kdepim, but still can't think of any other way of doing it
> > > > except to introduce timer-based calls to wait for the D- Bus
> > > > interface to become active. Yet other applications (KOrganizer etc)
> > > > don't seem to have this problem (or do they just ignore it?).
> > >
> > > IIRC KDBusServiceStarter is used there, not sure if that really waits
> > > until the corresponding service is available though. If you want to be
> > > really sure that KMail has been started, listening to the
> > > serviceOwnerChanged() signal might help.
> >
> > Thanks Volker. That helps, but even when that signal is received, the
> > actual interface isn't necessarily available yet, so it still looks as if
> > it's necessary to do a few timer delays.
>
> I had the same problem with the Kolab resource, which needs a special
> interface to show up to work.
> What I did to solve that was a introducing a nasty hack: After I created
> that interface in KMail, I added a dummy D-Bus service
> "org.kde.kmail.groupware". This way, I then use Qt to see if the
> org.kde.kmail.groupware service is up, which in turn also means my
> groupware interface/object is ready.
> Not a nice solution though. The code is in
> KMailConnection::waitForGroupwareObject() in
> kdepim/kresources/kolab/shared/kmailconnection.cpp.
>
> I think there is a similar problem with the "Open in Addressbook" function
> in KMail. which opens kaddressbook,

On Tuesday 04 August 2009, Kevin Krammer wrote:
> Wouldn't it be easier if an always existing object would emit a D-Bus
> signal when it has successfully created sub objects?
>
> Sure, it is a pity that QDBusInterface seems to test validity at
> creation time [1] thus not allowing the interface itself to emit that
> signal, but it still sounds less messy than to register another name.
>
> [1] maybe there is a way in the Qt4 bindings to allow a proxy object
> to be instantiated without introspecting the target

--
David Jarvie.
KDE developer.
KAlarm author and maintainer.
http://www.astrojar.org.uk/kalarm