Over the last few months, I’ve been working on a platform-wide session save/restore infrastructure. This serves a few purposes:
User-facing feature: Allows session state to be saved when the session ends (i.e. when the user logs out, reboots, etc.) and restored at the next login. It will capture what apps were running at log-out time, and relaunch them. Window size and position will be restored, as well as app-specific state.
Developer Experience: Replaces the per-app code to implement the conventional window geometry save/restore with a centralized implementation in GTK, and extends this to also save window positions and other window management state using a new Wayland protocol
Crash Resistence: It makes our apps more crash-resistant by periodically saving app state. If an app or even the entire session crashes, the next launch will use the periodic auto-saves to restore as much state as possible.
Encourages Updates: It’s currently a big burden for a user to reboot their system to apply updates, so users don’t do it as often as they should. Support for this save/restore infrastructure will make reboots less disruptive, which will hopefully encourage our users to keep their systems more up-to-date and thus more secure.
The feature doesn’t really work without the participation of apps. To that end, I’ve created the Session Save/Restore Initiative to track apps that are porting to this API. The initiative also has comprehensive instructions for enabling this feature in your app. Please take a look, and please consider porting your app!
This API is, overall, still a work in progress. But I feel that it has reached a point where drastic changes are unlikely and apps can start looking at porting early.
We’re aiming for the feature to be ready by GNOME 50, but there’s still a discussion to be had about when the feature will be exposed to users. We probably shouldn’t expose the feature unless, at the very least, the Core apps that ship by default with the GNOME desktop support it
Will this make it possible to place specific windows at their last position?
Example:
A presentation app has a “editor” window on the laptop screen and a “slideshow” window maximized on the projector screen. After closing the “slideshow” window (keeping the “editor” one open), can I reopen it on the projector screen?
Yes that’s one of the intended use-cases of the Wayland protocol. Apps will be allowed to ask the compositor to save window management state (including a window’s position, monitor, workspace, z-order, and any other compositor-specific settings like GNOME’s always-on-top setting) and then can ask for this state to be restored later. Ultimately the compositor remains in control of what happens then and how much state is restored, but yes I imagine compositors would allow apps to put the window back where it last was
Ultimately the compositor remains in control of what happens then and how much state is restored
Does this mean that, even if app does not ask for state to be restored, GNOME will still restore all apps and their state if this feature is enabled? I think that would be what users expect to happen.
I’m investigating the implementation of the session recovery for the win32 backend, but I’m not sure how it should behave…
it seems on Linux the GTK_RESTORE_REASON_* are received from DBus, right? is it documented somewhere which value corresponds with which scenario?
should the app automatically restart at next logon? or only restore when manually started?
in the 2nd case, should the restored session be loaded only if the app is started without parameters? I suppose if the user tries to open a file with the app then the session restore should be skipped?
what happens if the app is non-unique and several instances/processes are running when the session ends? should there be several backup files, or the last to close will overwrite the previous ones?
hey, one quick (and maybe stupid) question, will it be possible to store the information per display? When I’m in my laptop most of my windows are full screen, but when I connect the external display, The windows are floating, As it is huge and usually I’ve got more than one visiable. Is it possible that the new system is able to remember this kind of nuances?
If we’re logging back in after a full-session crash, then RECOVER is returned. However, I’m considering adding another restore reason specifically for the “whole session crashed” case
If the individual app crashed (i.e. exited without explicitly unregistering from the save/restore infrastructure), then we return RECOVER the next time it’s launched.
If we’re logging back in after the session ended normally and session restore was turned on, then RESTORE is returned
In all other cases, NORMAL is returned
PRISTINE is never returned
Apps should automatically restart at next logon
Nope, even with command-line arguments we restore state. The state restoration happens before the various entry points. So an app will see:
restore-window emitted repeatedly, for each saved window
activate / open / command-line / etc emitted
Apps already need to be handle this. Any of these entry points can be emitted even if the app has been running for a while.
There should be several files. The DBus protocol provides apps with an “instance ID” for this purpose. Each instance of an app gets an instance ID assigned and saved to disk when it registers. At next login, if there’s two instances of an app in the list, the app is simply launched twice. The first one to register will be given the first instance ID, and the second one to register will be given the second instance ID