GNOME Bugzilla – Bug 683488
Clear up some conceptual problems in the new sessionMode
Last modified: 2012-09-06 15:04:05 UTC
See patches. While the 2nd patch serves primarily for documenting intent, I consider the 1st one mildly important: gnome-shell --list-modes | grep lock-screen => yup, it's there gnome-shell --mode=lock-screen => Crash! It clearly doesn't make sense to start in a "temporary" mode like the lock screen, so we should make this very clear to users (in fact, users don't really need to know about those temporary modes in the first place, they are just an implementation detail)
Created attachment 223639 [details] [review] sessionMode: Introduce the concept of "primary" modes With the recent session mode changes, there is now a mix of modes that are meant to apply to the entire session (specified as parameter to the --mode command line switch) and temporary modes like the lock screen; introduce a property to make the difference explicit, and only allow "primary" modes to be specified on the command line.
Created attachment 223640 [details] [review] sessionMode: Add an explicit property to allow mode changes While this shouldn't really be necessary in practice (when extensions are allowed, there are no guarantees whatsoever, same applies to the run dialog), an explicit property documents clearly which modes are meant to be invariant and which are not.
Review of attachment 223639 [details] [review]: Sure (I had the same comment on Jasper's original patch, but I didn't consider the --list-modes case)
Review of attachment 223640 [details] [review]: No. All modes allow changes, because all modes have a lock-screen. Also, from the lock-screen you need to go back, so popMode must be allowed.
Attachment 223639 [details] pushed as 8109dd6 - sessionMode: Introduce the concept of "primary" modes Ah yeah, lock-screen was of course meant to have allowModeChange set; I'm not sure I agree that *every* mode should support lock, but as mentioned before, I mostly care about the pushed patch anyway ...