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, [email protected], http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5
