Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
dev:session-management [2009/07/19 14:24] – apparently you can't have "code" markup in a heading kelnos | dev:session-management [2009/07/19 14:44] – add bits about session startup kelnos | ||
---|---|---|---|
Line 80: | Line 80: | ||
=== Value of the Name Key === | === Value of the Name Key === | ||
- | The '' | + | The '' |
But for apps started by the user that get saved in the session, how do we figure out a useful value to put in the '' | But for apps started by the user that get saved in the session, how do we figure out a useful value to put in the '' | ||
Line 86: | Line 86: | ||
Options: | Options: | ||
- Use the value of the SmProgram XSMP property if present. | - Use the value of the SmProgram XSMP property if present. | ||
- | - Dig around in the system and user .desktop file directories ('' | + | - Dig around in the system and user .desktop file directories ('' |
- When the session is saved, find the WM_CLIENT_LEADER window and take its _NET_WM_NAME property. | - When the session is saved, find the WM_CLIENT_LEADER window and take its _NET_WM_NAME property. | ||
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? |