Properly check for systray being available
Review Request #121885 - Created Jan. 6, 2015 and submitted
The "org.kde.StatusNotifierWatcher" is just a watcher/helper, not the actual systray object, that's "org.kde.StatusNotifierHost-$PID". Because Plasma appends the PID, we cannot check directly for it being present on the bus, so we check the org.kde.StatusNotifierWatcher.IsStatusNotifierHostRegistered property that's meant to be used for this.
Plus QSystemTrayIcon::isSystemTrayAvailable() is actually returning always true, because the Watcher is in kded and is /always/ present.
This also fixes many apps with KSNI crashing on plasma exit, bug 339707 (though I believe this is not the direct cause for that bug)
Things do not crash anymore and the ::isSystemTrayAvailable() now returns correct value.
I don't see a deadlock here, unless StatusNotifierWatcher calls this method itself :-)
Just one thing though: this creation of a QDBusInterface will auto-start the service (i.e. autoload the kded module), if it wasn't loaded already. Is this desired?
(so yeah, if the constructor calls this method we have a problem ;)
I don't know the whole design around this, but this patch looks ... hackish (and possibly slow) to me.
It looks very implementation-dependent...
Is the absence of a well-known dbus name because there could be more than one systray?
Looking at this again, the first patch seemed better to me, is there any reason for the change?
"StatusNotifierWatcher is another kded module, it can't respond because we're blocked awaiting a reply from ourselves." makes no sense to me. In-process DBus calls definitely work. QtDBus turns it into a direct method call. In fact this makes the v1 of the patch really fast :)