| Next revision | Previous revisionNext revisionBoth sides next revision |
| dev:session-management [2009/07/19 13:59] – created 67.188.6.70 | dev:session-management [2009/07/19 14:21] – fix some typos 67.188.6.70 |
|---|
| * This is somewhat abusing the XDG autostart spec. We'd end up either setting ''Hidden=true''/''NoDisplay=true'' to keep anyone else from seeing it, or (more likely) using ''OnlyShowIn=XFCE;'' to achieve the same result. But still, it's a little nasty. | * This is somewhat abusing the XDG autostart spec. We'd end up either setting ''Hidden=true''/''NoDisplay=true'' to keep anyone else from seeing it, or (more likely) using ''OnlyShowIn=XFCE;'' to achieve the same result. But still, it's a little nasty. |
| * Third-party tools might wipe out our session-management-specific keys upon editing them, if they're not written in a sane way. This is a minor consideration, I think. | * Third-party tools might wipe out our session-management-specific keys upon editing them, if they're not written in a sane way. This is a minor consideration, I think. |
| * It's more difficult to clear the session, both manually and programmatically. Instead of just deleting out a file or directory, you have to check each file to see if it's a plain-vanilla XDG autostart file, or if it's part of a saved session. This also raises the question of what a "session removal" really is: is it just removing apps restored by the session manager, or does it also mean clearing out all XDG autostart files, even those created by the user or auto-created by some random app? | * It's more difficult to clear the session, both manually and programmatically. Instead of just deleting a file or directory, you have to check each file to see if it's a plain-vanilla XDG autostart file, or if it's part of a saved session. This also raises the question of what a "session removal" really is: is it just removing apps restored by the session manager, or does it also mean clearing out all XDG autostart files, even those created by the user or auto-created by some random app? |
| * Using the XDG autostart dir makes having more than one saved session difficult (well, not too difficult: you just have an extra key in the file with the session name; but of course this makes the previous point more complicated, and makes the point about third-party tools fail completely, since they'll likely show app apps from all sessions). However, I've often thought having multiple sessions is a rarely-used feature that just bloats xfce4-session, complicates the code, and is confusing to end-users so I'd consider removing it. | * Using the XDG autostart dir makes having more than one saved session difficult (well, not too difficult: you just have an extra key in the file with the session name; but of course this makes the previous point more complicated, and makes the point about third-party tools fail completely, since they'll likely show all apps from all sessions). However, I've often thought having multiple sessions is a rarely-used feature that just bloats xfce4-session, complicates the code, and is confusing to end-users so I'd consider removing it. |
| |
| I'm currently leaning toward storing these in the XDG autostart directory. | I'm currently leaning toward storing these in the XDG autostart directory. |
| ClientId=abcdefg-0123456789\\ | ClientId=abcdefg-0123456789\\ |
| Priority=40\\ | Priority=40\\ |
| RestartCommand=xfdesktop --sm-client-id abcdefg-0123456789 | RestartCommand=xfdesktop --sm-client-id abcdefg-0123456789\\ |
| CurrentDirectory=/home/brian\\ | CurrentDirectory=/home/brian\\ |
| RestartStyle=RestartImmediately'' | RestartStyle=RestartImmediately'' |
| * The aforementioned issue with apps being unable to automatically add themselves to the session at install time goes away. All they need to do is drop a .desktop file with the custom keys into the system autostart directory. | * The aforementioned issue with apps being unable to automatically add themselves to the session at install time goes away. All they need to do is drop a .desktop file with the custom keys into the system autostart directory. |
| * Each app is stored in its own file, so adding and removing single apps from the session at once is trivial. | * Each app is stored in its own file, so adding and removing single apps from the session at once is trivial. |
| | |
| | ==== Other Issues ==== |
| | |
| | === 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. |
| | |
| | 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? |
| | |
| | Options: |
| | - 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. |
| | - 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. |
| | |
| | The third option seems ideal, though for many apps it might be odd (for example, currently my web browser's title bar says "dev:session-management [Xfce wiki] - Mozilla Firefox", which is a little unfriendly). The second option is better for usability than the first option (apps could put strings in the SmProgram field that aren't intended to be user-visible), but might be slow given the number of files on the filesystem that might need to be inspected. Also I believe the SmProgram field is optional. |
| | |
| | It's possible that SmProgram won't be set, and no matching .desktop file can be found. The _NET_WM_NAME method will be the only option in that case. I'm thinking the _NET_WM_NAME option might be our first choice, anyway, so the other options wouldn't need to be implemented at all (I'd be very surprised to see an app not name its client leader window). |
| |
| ===== Integration With XDG Autostart ===== | ===== Integration With XDG Autostart ===== |
| |
| ==== Intentional Multiple Copies ==== | ==== Intentional Multiple Copies ==== |
| | |
| | Sometimes we actually **do** want multiple copies of an app in the session. Say we have a text editor that opens documents in different processes, or something like that. If you have 5 documents open, and you save your session, you're going to want all 5 documents opened in 5 copies of the app when your session gets restored. |
| | |
| | One of the main issues with this is .desktop file naming. The naive method would be to create the desktop-file-id by taking and munging the ''Exec'' key in some way, or by taking the ''Name'' key, lowercasing it, and substituting dashes for spaces. If there are multiple copies of the app, this breaks. I suppose we can just append a sequential identifier to the end of each desktop-file-id, but that sounds wrong to me for some reason. |
| | |
| | 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). |