Review Request: Avoid QDBusConnection Qt warning message for each KUniqueApplication

[Thiago Macieira]

On Sunday, 15 de January de 2012 18.28.28, Martin Koller wrote:
> qWarning is in QDBusDefaultConnection ctor
> 
> > Did I place the warning in the wrong object in QtDBus?
> > Or is there something *else* creating that connection?
> 
> no, it's the call to QDBusConnection::sessionBus()
> which creates the QDBusDefaultConnection object which throws that warning.

I know. My question is: why was QDBusConnection::sessionBus() called before 
QCoreApplication was created? Can't we fix *that* by initialising it later?

> > Your description still requires the QCoreApplication object to be created
> > before the fork. It doesn't matter that you're going to close that open
> > and
> > open a new one after the fork: it's still a bad idea. Some Unix operations
> > do not survive forks, like creation of threads. If you do that, I'm
> > pretty sure QProcess will be irreparably broken.
> 
> Sorry, I don't understand that.
> Nevertheless, I tried now what you've suggested above, namely to create my
> own QDBusConnection object to the session bus. This seems to work now,
> however as I'm new to DBus, I do not fully understand everything.
> What I've found out is that the KUniqueApplication's DBus call to
> /MainApplication only works if I create a QDBusConnection object on the
> session bus only if it uses the same name as the Qt-internal
> QDBusDefaultConnection object, which is "qt_default_session_bus", even when
> I would create my QDBusConnection objects in the way that they live as long
> as the app lives.
> Does that mean that a registered Object on DBus is linked to the
> QDBusConnection's name ?

No, it means you really did not understand the code you're trying to change.

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've updated the diff https://git.reviewboard.kde.org/r/103699/diff/2/

I can't find my password. Someone convinced me a while ago to use passwords 
generated with keepassx, especially because the KDE accounts kept getting 
locked because of passwords being too easy to crack.

Can you send the patch?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      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: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120115/c04d7b28/attachment.sig>