GNOME Bugzilla – Bug 673182
two-part DBus registration causes problems
Last modified: 2021-07-05 14:35:08 UTC
nm-applet currently fails to recognize that gnome-shell 3.4 is running, because when it sees org.gnome.Shell appear on the bus, it queries its ShellVersion property, and is told that org.gnome.Shell does not implement org.freedesktop.DBus.Properties. davidz says the shell really shouldn't be putting objects up on the bus first and then adding interfaces to them later. IIRC, the reason we had to do the dbus-name-claiming from C was that it needs to happen synchronously before we register with gnome-session, and the old gjs dbus code didn't implement synchronous calls. Now that it's using GDBus, maybe this wouldn't be a problem? (It would still require some reorg since currently we don't run any JS until after having registered with gnome-session.)
This also causes problems for the browser plugin -- it notices that the Shell name has appeared, and then fails when it tries to query things like the ShellVersion as well.
I think the conclusion was roughly that it makes sense for components to have an "instance start lock" and then acquire the dbus name later. The "instance start lock" could be another DBus name. http://lists.freedesktop.org/archives/dbus/2011-April/014299.html
So, gnome-shell should change to have some instance start lock (which could be the compositor selection actually), and only acquire the dbus name at the end of initialization.
It needs to lock ownership of org.freedesktop.Notifications too though. Or alternatively, we need to juggle things around in such a way that notification-daemon's .service file is only visible in fallback mode (which, as Matthias noted in another bug, is probably not easy if dbus-daemon is started before gnome-session).
Rather than making DBus activation be more dynamic, I think in this case, since we in GNOME control both code bases, we should make the org.freedesktop.Notifications.service file invoke a binary gnome-notifications-service which checks the running session type internally and starts the right binary. Basically: if (g_settings_get_session_type() == "fallback") execve ("notification-daemon"); else { g_dbus_monitor ("org.gnome.Shell", /* callback to exit (0) when shell appears */); }
The problem with that kind of approach is that you have to handle all the 'minority' desktops, so it has to be more like: if (session == fallback || session == xfce || session == lxde || session == mate...) or maybe turn it around to if (session == gnome3) wait for shell else exec notification-daemon
Doesn't this mean that any notifications before the shell comes up are simply dropped, unless we do a handoff? We can't just have notification-daemon re-play the messages, since we do PID tracking, unless we can hack that.
(In reply to comment #7) > Doesn't this mean that any notifications before the shell comes up are simply > dropped That's already the case now; once the shell grabs org.freedesktop.Notifications, notification-daemon can't, but the shell isn't actually implementing the notifications interface yet, so any attempts to put up notifications will fail.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.