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
I saw the gtk session saving feature was postponed to a future release, and from the MR it seems related to the need to support async processing during shutdown.
Is it really unavoidable? Are there usecase examples that require async shutdown?
My concern is that for implementing the saving support on Windows, the shutdown APIs are synchronous, we are supposed to respond to the system notification once done, after which the system will attempt to kill the app.
The main issue is that the entire system is currently asynchronous:
user closes app A
app A starts saving its state while the windows are closed
app A relinquishes the name on the session bus
user starts app A again
the system instantiates app A while the previous instance is still busy saving state
there is no state for the new app A instance to restore
the state for the old app A instance is dropped
This will lead to data loss and an inconsistent state.
We discussed various approaches at the GTK hackfest in February, and we have a few ideas we wish to iterate early in the next development cycle, before committing to an API.
Getting things right on Linux is the priority; we are aware that other platforms have more synchronous approaches, so we need to ensure that Linux is covered.
Is there a page somewhere describing how this is planned to work from the user’s perspective? Are there new user settings to opt in/out of this? Is it possible for users to disable automatic restoration on login but still have apps restore when the user launches them manually?
On a system level, no not in GNOME. However, the API allows apps to implement this themselves, in their own settings. I imagine that apps like web browsers, text editors, IDEs, etc will make use of this functionality.
And now that I think more about it, this would be useful regardless of what happens at login: just quit an app and open it again during the same session.
