Xfce Wiki

Sub domains
 

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Last revisionBoth sides next revision
dev:session-management [2009/07/19 14:24] – apparently you can't have "code" markup in a heading kelnosdev:session-management [2009/07/19 14:53] – add section on session saving kelnos
Line 80: Line 80:
 === Value of the Name Key === === Value of the Name Key ===
  
-The ''Name'' key in the desktop file would provide a user-readable name for the application.  This is useful in a session editor (which ends up being the autostart editor).  For autostart/session files installed by the application, this is already taken care of us, and the names are even probably localized for us.+The ''Name'' key in the desktop file would provide a user-readable name for the application.  This is useful in a session editor (which ends up being the autostart editor).  For autostart/session files installed by the application, this is already taken care of for us, and the names are even probably localized for us.
  
 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 ''Name'' key? 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 ''Name'' key?
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 (''$XDG_DATA_DIRS/applications'') and try to find an application with a matching ''Exec'' key (or at least one with the same argv[0]), and use the ''Name'' key from there.+  - Dig around in the system and user .desktop file directories (''$XDG_DATA_DIRS/applications'') and try to find an application with a matching ''Exec'' key (or at least one with the same argv[0]), and use the (probably localized) ''Name'' key from there.
   - When the session is saved, find the WM_CLIENT_LEADER window and take its _NET_WM_NAME property.  This is also beneficial to allow the user to uniquely identify each entry if several copies of the same app are saved to the session.  Usually this value will be localized as well.   - When the session is saved, find the WM_CLIENT_LEADER window and take its _NET_WM_NAME property.  This is also beneficial to allow the user to uniquely identify each entry if several copies of the same app are saved to the session.  Usually this value will be localized as well.
  
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?  I don't think so... I'm not even sure how that would work in practice (unless the app has some sort of --dont-connect-to-the-sm startup switch, which would strike me as very odd). 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?  I don't think so... I'm not even sure how that would work in practice (unless the app has some sort of --dont-connect-to-the-sm startup switch, which would strike me as very odd).
 +
 +===== Session Startup =====
 +
 +==== Priority ====
 +
 +GNOME's new session management flow drops the concept of integer priority values and simplifies it down to a series of five startup phases.  Four of the phases include various usually-required core desktop applications, while the last phase includes pretty much anything else.
 +
 +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 way it'll set its struts before xfdesktop starts, which means xfdesktop won't have to redraw itself after _NET_WORKAREA changes.
 +
 +This also has the benefit of not making fundamental protocol changes.  So far I haven't suggested anything that's "incompatible" with XSMP as we know it, but doing the phase thing would change how things work quite a bit and would only work properly for Xfce apps.
 +
 +==== Client Interaction on Startup ====
 +
 +Ok, since that I just said I haven't talked about making any fundamental changes, I'll suggest one now.
 +
 +As mentioned, GNOME's new SM flow defines five startup phases.  The fifth startup phase, the Application phase, is somewhat special.  For the first four phases, the standard SM practice of waiting for each app to connect to the SM before moving on is still in effect.  However, for the Application phase, the SM doesn't really care if the app connects to it at all.  Effectively, immediately after the SM has fork()ed and exec()ed the last app in the Application phase, startup is complete from the SM's perspective.
 +
 +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.  We'll still do parallel startup, and it'll still follow the priority numbers for the parallel startup groups for apps with priority values that put them in the Desktop phase (so we can set the WM's priority to 25 and the panel's priority to 30 and be sure that the WM has fully started before the panel starts).
 +
 +However, once we get into the Application phase, the actual priority value is effectively ignored.  We'll sort the apps in priority order and start them in that order (but still in parallel), but we won't wait at all for any apps to connect to the session manager before moving on to the next numerical priority group (and, similar to GNOME's method, we won't really care if the app even connects to the SM at all).
 +
 +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 ''Exec'' key in the .desktop file rather than the ''RestartCommand'' key).
 +
 +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?  On first glance, I'm not sure, but I'd lean toward yes, we remove it.
 +
 +===== Session Saving =====
 +
 +==== Multiple Saved Sessions ====
 +
 +As mentioned above, I'm strongly considering removing the feature to have more than one saved session.  However, the architecture proposed does not rule out multiple sessions, so this could be added (or added back if removed) without causing problems.
 +
 +==== Save Session By Default ====
 +
 +Assuming session saving actually works properly (I know, big assumption), I think most (all?) of the time we'll want to default to always saving the session, and we'll probably want to make it harder to disable this.  Basically this just means removing the checkbox from the logout dialog, but leaving it in the settings dialog.  Or maybe we'd have a 3-way option in the settings dialog for:
 +  - 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.  The new xfce4-session would default to the first option.
 +
 +==== Checkpointing ====
 +
 +Another option migh be a 'checkpointing' mode in which the session gets automatically saved every X minutes while active.  This way, unexpected occurrences (power failure, system crash, etc.) wouldn't disrupt the user's state too much.  Of course, sending a SaveYourself message to all clients often might cause a noticeable delay.  We can set the 'fast' field to True in the SaveYourself message, but it's unclear as to whether or not apps generally honor that value.  Regardless, one app's definition of 'fast' might not agree with the user's (and probably would be machine-speed-dependent).