Avoid QDBusConnection Qt warning message for each KUniqueApplication

[David Faure]

Long ago, Thiago wrote:
> Here's *should* go on:
> 
> 1) KUniqueApplication connects to D-Bus using a private connection
> 
> 2) it checks if the application is already running. If it is and we would 
> fork, we simply ask the running instance to show a new main window. Then we 
> exit.
> 
> 3) if it wasn't running, it forks. The parent process waits for the child 
> process to register itself on the bus using the same private connection. The 
> child process closes its end of the private connection.
> 
> 4) the child process initialises the QCoreApplication object
> 
> 5) the child process opens the default, shared session bus connection and 
> registers itself on the bus
> 
> 6) the parent process notices the child is up and running, so it exits with 
> _exit(0) (not exit(0)).
> 
> You're getting the warning because steps 4 and 5 are inverted. Your patch 
> should de-invert them by making the very first call to 
> QDBusConnection::sessionBus() happen after the QCoreApplication's
> constructor has finished running. That means it can run in the KApplication 
> constructor body or in the KUniqueApplication constructor body, but not 
> before.

I had a look at this issue, and this is missing a major feature of the current 
KUniqueApplication. In the standard case (not already running, forking 
enable), the parent will call "/MainApplication newInstance()" on the child.
This is why the child registers to DBus right after forking (and before the 
QCoreApp ctor).

If I try to make it register using a private connection, then the call appears 
to fail -- I'm not exactly sure why.

The reason Waldo (iirc) made it that way rather than the steps you describe 
above, is that this fixes a race condition between 2) and 3) above, I think.
The parent wants to always call newInstance, whether this ends up on its own 
child process, or another instance started meanwhile.
I think your idea above leads to a race in such a case. At step 3, the child 
will fail to register (already running), and the parent will never call 
newInstance on the newly-started instance, so no new window.

I know that I said "not a problem in KF5 anymore", but kdelibs4 is still going 
to be used for a very long time, and warnings on startup don't make it appear 
very polished... Could you take a look at it -- based on the current code 
rather than a theoretical idea of how it should work? :-)

My current broken patch is 
http://www.davidfaure.fr/2012/kuniqueapp_broken_fix.diff

The change from QDBusConnectionInterface* to QDBusConnection as the return 
value of tryToInitDBusConnection() -- which introduces a bit of noise in the 
patch -- is only due to the very last hunk: so that we can make the call from 
parent to child using the private connection rather than sessionBus().

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5