GitLab

We've discussed the idea of having the session persist restarts in the past, but I don't think we've ever written it down formally, so I'm making a start here.

Problems

• Doing system updates safely requires rebooting, both for package-based and image-based systems
• Currently there's no way to retain your session across reboots, so people have to recreate their working environment every time
• This disincentivizes timely updates, as well as investing time into e.g. organizing tasks across multiple workspaces
• The system has no way to "pause" background apps to save power or increase performance

Goals

• Enable people to do system updates without having to think about closing/restoring all their open windows. Ideally it should be as simple as clicking "Update", going for a coffee break, and coming back to the system in the exact same state, but fully updated
• Save people the busywork that comes with setting up your session from scratch on every reboot
• Give people confidence that work they put into organizing their session (window positions, workspaces, etc.) is not ephemeral
• Allow the system to shut down apps in the background when it deems this necessary/advantageous (e.g. when the battery is low)

Relevant Art

Android

TBD

iOS

TBD

macOS

TBD

Ideas

On the shell side, this is most likely fairly straightforward:

• Remember the size, position, and workspace of every window persistently
• Restart apps in that same configuration after reboot

One potential issue is the speed of apps starting up. It would be good to avoid having windows randomly pop up for a while after a reboot :)

The trickier part is: What do apps do once restarted, and how do we store their state?

The main ideas we've discussed for this are

• Do some kind of memory dump of every open app, and restore that (Likely too brittle to work at scale)
• Have apps handle this themselves and save only what they need to restore. Apps that do not indicate to the shell that they're equipped to handle this are closed before shutdown, and users are shown a warning about it (similar to the current inhibit, but opt-out rather than opt-in).

Some other things to consider:

• Multiple windows, multiple tabs within windows, etc.
• In-app navigation
• Scroll position
• Unsaved changes to files