Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
dev:session-management [2009/07/19 14:26] – more typos, localization note kelnos | dev:session-management [2010/10/02 17:26] (current) – external edit 127.0.0.1 | ||
---|---|---|---|
Line 121: | Line 121: | ||
Is there any situation where the user would want one copy of the app in autostart (but not session managed), and another copy of the app session managed? | Is there any situation where the user would want one copy of the app in autostart (but not session managed), and another copy of the app session managed? | ||
+ | |||
+ | ===== Session Startup ===== | ||
+ | |||
+ | ==== Priority ==== | ||
+ | |||
+ | GNOME' | ||
+ | |||
+ | While this approach does have its merits, I'd like to stick with the numerical priority values for now. If needed, we can define phases by convention (e.g., prio < 10 means init phase, prio < 20 means WM phase, etc.). | ||
+ | |||
+ | Random unrelated note: the panel should have a lower priority value so it starts in the group prior to xfdesktop. | ||
+ | |||
+ | This also has the benefit of not making fundamental protocol changes. | ||
+ | |||
+ | ==== Client Interaction on Startup ==== | ||
+ | |||
+ | Ok, since that I just said I haven' | ||
+ | |||
+ | As mentioned, GNOME' | ||
+ | |||
+ | This is good because the Application phase can contain any app, some of which may misbehave, which might cause the SM to halt for a while to wait until the app times out. In theory, the apps in the first four phases are all core desktop apps, so we (usually) have some control over them and can expect them to behave properly (and when they don't, we know who to beat up on until it's fixed). | ||
+ | |||
+ | So, in line with my unofficial conventions above of defining the phases in terms of priority levels, we might just have two phases: | ||
+ | - Desktop | ||
+ | - Application | ||
+ | We could define a priority level (let's say 50 for the sake of example) such that numbers lower are sorted into the Desktop phase, and numbers higher are sorted into the Application phase. | ||
+ | |||
+ | However, once we get into the Application phase, the actual priority value is effectively ignored. | ||
+ | |||
+ | As a side effect, all standard XDG autostart apps get assigned to a default priority value that's somewhere in the Application phase range, and will get started just like any other session-managed app (except that we start it using the '' | ||
+ | |||
+ | FIXME: if an app in the Application phase (that was previously saved in the session and is **not** a standard plain-vanilla XDG autostart file) fails to connect to the session manager, do we remove it from the session? | ||
+ | |||
+ | ===== Session Saving ===== | ||
+ | |||
+ | ==== Multiple Saved Sessions ==== | ||
+ | |||
+ | As mentioned above, I'm strongly considering removing the feature to have more than one saved session. | ||
+ | |||
+ | ==== Save Session By Default ==== | ||
+ | |||
+ | Assuming session saving actually works properly (I know, big assumption), | ||
+ | - Always save session on logout | ||
+ | - Never save session on logout | ||
+ | - Ask whether to save the session on logout | ||
+ | The third option would obviously display the checkbox in the logout dialog as we do now. We still want to maintain the ability to not save the session, though hopefully this would mainly just be used in kiosk environments where the sysadmin wants the session to start fresh every time it's started. | ||
+ | |||
+ | ==== Checkpointing ==== | ||
+ | |||
+ | Another option migh be a ' |