GNOME Bugzilla – Bug 642666
Persistence Property announced too late
Last modified: 2011-02-28 19:01:21 UTC
If krb5-auth-dialog is started via /etc/xdg/autostart/ during session startup then it can't detect the persistence property on gnome-shell's notification service and therefore falls back to using a tray icon. If I add a "sleep 10" to krb5-auth-dialog's desktop file to wait until the shell is finally up, the check for persistence succeeds and a resident notification is being used. IMHO the check for the persistence property must succeed for applications if run after the GSM_MANAGER_PHASE_DESKTOP, probably even earlier otherwise apps might fall back to using a tray icon although the could make use of the improved notification system.
Done some more investigation: we fail to detect the persistence property since during early session startup gnome-shell doesn't have it's org.freedesktop.Notifications D-Bus interface in place. Therefore applications using notify_get_server_caps will spawn the old notification daemon. This one will then return that it doesn't support resident notifications. When removing notification-daemon notify_get_server_caps fails completely. Are there any plans to fix this? It would be good enough to be able to reliably check that the shell is still starting up.
We really, really need to have gnome-session not spawn everything in parallel. I can't think of a better way to fix this.
Assuming the system is set up correctly, gnome-session won't start any apps until mutter has signaled that it is ready, which definitely happens *after* running the shell initialization code. The bug probably has something to do with gjs dbus calls being async; if the acquire_name() doesn't hit the bus until after the main loop starts (and after mutter redraws everything?) then it's possible that other apps could get started during that time.
LP(In reply to comment #3) > Assuming the system is set up correctly, gnome-session won't start any apps > until mutter has signaled that it is ready, which definitely happens *after* > running the shell initialization code. Nope, see incoming patches.
Created attachment 181944 [details] [review] mutter: early init
Created attachment 181945 [details] [review] claim dbus names early
Sorry, ignore the screensaver VT switch bits in statusMenu.js in the second patch, was something else I was working on.
Comment on attachment 181944 [details] [review] mutter: early init Hm... ah, meta_prefs_init() calls meta_plugin_manager_load(), but meta_plugin_manager_initialize() doesn't get called until meta_display_open(). So an easier fix would be to just move the xsmp stuff to after the meta_display_open().
Comment on attachment 181945 [details] [review] claim dbus names early modulo the early_init() issue, this all looks good except: >+ if (!g_getenv ("GNOME_SHELL_NO_REPLACE")) >+ { --xephyr is gone now, so we should be grabbing org.gnome.Panel unconditionally. It would be nice to do the 4 RequestNames in parallel rather than serial... but I'm not sure it's safe to run the main main loop at this point (mutter may already have queued up some idles or something?) and I don't think libdbus would let you use a different one. So maybe that can wait for the GDBus port.
(In reply to comment #8) > (From update of attachment 181944 [details] [review]) > Hm... ah, meta_prefs_init() calls meta_plugin_manager_load(), but > meta_plugin_manager_initialize() doesn't get called until meta_display_open(). > > So an easier fix would be to just move the xsmp stuff to after the > meta_display_open(). The current placement seems deliberate to me; there is a comment above saying having the session data is necessary before we potentially manage any windows.
Comment on attachment 181944 [details] [review] mutter: early init (In reply to comment #10) > The current placement seems deliberate to me; there is a comment above saying > having the session data is necessary before we potentially manage any windows. Ah, right. So, in response to the "gnome-shell shouldn't be a python script" bug, I had started working on finally turning mutter into libmutter, and libgnome-shell into a binary that links against it. So if we need to change the plugin init sequence anyway, maybe we should go all the way and do that? (If not, this patch looks fine.)
(In reply to comment #11) > So, in response to the "gnome-shell shouldn't be a python script" bug, I had > started working on finally turning mutter into libmutter, and libgnome-shell > into a binary that links against it. So if we need to change the plugin init > sequence anyway, maybe we should go all the way and do that? I didn't even look at doing that seriously; there's a lot of code and my instict was that it would be too invasive for 3.0, but I don't know; how far along did you get? > (If not, this patch looks fine.) Ok, I'll commit these then; it'll be conceptually clearer for when we do have libmutter anyways.