Viewer behaves confusingly if the daemon starts for the first time since user logged in

[Rafał Cieślak]

Steps to reproduce:
1. Use a HDD drive. The slower it is, the greater chances you'll be affected.
2. Disable daemon automatic startup on login.
3. Log off and back in.
4. Start the viewer. (If you start the daemon first, run the viewer for second time since login, or if the daemon has been running since last login you will not be affected)

What should happen:
1. The viewer should display status message "Starting the daemon..."
2. After a second, trophies should be displayed.

What happens instead:
1. The viewer displays "Starting the daemon" message, and waits in this state for a second or few.
2. For next 5-10 seconds, the viewer displays "Failed to connect to daemon"
3. Afterwards it displays "Starting the daemon" again, and everything is back to normal.

Why this is wrong:
The 'Failed to connect to daemon' message confuses users, and increases viewer's initiation time.

Why this happens:
Loading twistd, daemon and initializing it (which reads accoms colelctions) takes some time on drives which are not too fast. If during this time the viewer tries to connect to the daemon, it will fail indeed. When the daemon is started on login, it will initiate before one launches the viewer. If the drive is fast enough (e.g. SSD) this bug does not appear. If the daemon is started for the second time in one login session, it takes much much less time to start (I guess it's some magic caching) and thus this bug is not present in such cases.

Ideas on how this can be solved:
The simplest fix is to increase waiting time, but that increases the time the viewer needs to start in all cases.
A more clever fix would be to wait for the "accomplishments-daemon --start" to return, and then connect to the daemon via dbus. Currently we blindly run "accomplishments-daemon --start &" and try connecting after some time. Of course the launched command may not block viewer's code execution, as that would freeze UI. Therefore we need a clever way to be notified when this command returns.

[Rafał Cieślak (rafalcieslak256)]

I managed to fix this by starting the daemon launcher in a separate thread, and successfully integrating the thread with GObject. That new thread waits for launcher to exit, and then instructs GObject to call a function that connects to the daemon etc.

[Rafał Cieślak (rafalcieslak256)]

Tested the fix on a machine with super slow HDD, where daemon takes 15-20 seconds to start. The confusing behavior is no longer present, and the UI does not freeze.