GNOME Bugzilla – Bug 591171
Allow gnome-shell to replace itself
Last modified: 2009-08-27 19:34:54 UTC
When gnome-shell is running, executing 'gnome-shell --replace' crashes the shell and restarts metacity and gnome-panel. Expected behavior is quitting the old gnome-shell session and starting a new one instead. This would be useful to be able to run from ~/gnome-shell/install/bin on startup, but replace it with an experimental ~/gnome-shell/source version when developing. Bonus points for restoring the installed version when the experimental version crashes.
Created attachment 141519 [details] [review] Only respawn if gnome-shell exits abnormally If Mutter exits with an exit status of 0, then that most likely means that it was replaced by another window manager and we shoudln't try to start the previous window manager and the panel. (We don't actually know about the panel, but assume that if someone is replacing us they know what they are doing.) When Mutter exits with a signal, we know we want to restart. When Mutter exits with a non-signal non-zero exit status, it's ambiguous - we could be exiting because we lost the connection to the X server, or because of a assertion failure in gnome-shell. We assume the latter; if the X server is gone, all that will happen is a bit of noise. To know why Mutter exited accurately, we always wait() and kill() the Mutter process, and then, if running in Xephyr, clean up Xephyr afterwards. This has the nice side effect of exiting when gnome-shell does and not forcing the user to close Xephyr manually.
Before we do too much more development on this script, I'm a bit unsure about having a persistent Python script hanging around. It doesn't matter for development, but if we're saying OS vendors should use this in desktop switching tools it's something to consider. This script is also growing a bit unwieldly because it tries to handle Xephyr and not. Maybe as a better medium-term we can move parts of this into the shell itself? Or possibly gnome-session, and keep the Xephyr parts in Python. So that's all unrelated to the patch, which looks OK. Small coding style thing: + if shell.returncode < 0: + # Python has no mapping for strsignal; not worth using + # ctypes for this. + print "Shell killed with signal %d" % - shell.returncode + else: + if shell.returncode == 0: Could merge into an "elif" here which seems slightly cleaner.
Comment on attachment 141519 [details] [review] Only respawn if gnome-shell exits abnormally if/else cleaned up and pushed. I'm not sure how practical moving stuff "into the shell itself" is until mutter is turned into a library. What I definitely don't want is invocations of mutter --mutter-plugins=gnome-shell or futzing around with LIBGL_ALWAYS_INDIRECT spreading over the place into vendor specific places or gnome-shell. I want there to be a gnome-shell program that you run and it works. One possibility is that we could have a stripped down shell version of the wrapper (or C even) without Xephyr and the recovery stuff, make that exec's mutter at the end to avoid a persistent process, and install that and leave the current wrapper for uninstalled installation. Doesn't seem to be urgent to me - I'd rather have something that's tested and robust for now.
I meant to say "vendor specific places or gnome-session" - the desktop file provides an option for some sorts of option-adding but it's pretty limited in scope.
Created attachment 141873 [details] [review] Restore GNOME based on GNOME configuration Instead of using pidof to find what was running when we started, and then hacking in a restart with hardcoded paths in /usr/bin, approximate how GNOME starts the panel and window manager. This fixes restarting Compiz correctly: http://bugzilla.gnome.org/show_bug.cgi?id=593184 And restarting gnome-shell correctly:
Comment on attachment 141873 [details] [review] Restore GNOME based on GNOME configuration >+def kill_legacy_gnome_panel(): Do we really still care about people using GNOME 2.24? We could just remove this. The patch looks good either way though.
(In reply to comment #6) > (From update of attachment 141873 [details] [review]) > >+def kill_legacy_gnome_panel(): > > Do we really still care about people using GNOME 2.24? We could just remove > this. > > The patch looks good either way though. Hmmm, that's a really tempting clean-up. Would allow closing the 'pidof' portability bugs, and I suspect that we're getting creeping 2.26 dependencies elsewhere. But I think I'll do that as a separate patch, though, since I'd want to add a check to gnome-shell-build-setup.sh as well.