Getting to a better “save & restore session” story would definitely be an improvement.
Of course, there are a ton of details left to figure out:
On top of that, it’d need some standardised protocol for toolkits to expose, and applications would need to be involved.
It’d be great to start working on this, but it’s a long term endeavour.
Just restarting firefox with its windows all in one place would be a good start, I think, and then maybe that app collaboration could be developed.
That’s the beauty of using flatpaks here; the application state would be frozen at that level. The right runtime and application version could be kept even if a newer one is there, and perhaps a notification that the app will be upgraded next time it shuts down. As for monitor geometry, that happens all the time with external monitors coming and going already.
For apps to shut themselves down and restore, yes. For CRIO to do it, no. (Although that definitely won’t work with X and needs some more work for Wayland.)
Agreed!
The “its windows” bit is also something gnome-shell cannot handle by itself.
Let’s say you end the session with 4 nautilus windows, each showing a different folder. The best gnome-shell can do on its own is launching nautilus 4 times on the next login, but that results in a single nautilus window for the home directory.
Could we leave restoring state to the app, including making it associate a persistent identifier (UUID) with each window (through some hint mechanism). Then, Shell could restore the window position when it encountered a known window.
Yeah, firefox handles this with whatever interal state tracker it has. (But not the workspace, obviously.)
Something like that is what I meant by “collaboration from apps” 
How would flatpaks help here versus a traditional package manager? This is state that has to be stored and synced by the desktop environment, it’s unclear what the flatpak runtime would be able to do that is special when it comes to state that is invalid or out of date if e.g. an app is updated and it needs to request that the desktop environment clear or update its stored state.
Yes, this happens all the time already, but the question is what to do in that case? There are a lot of ways this could be done. When starting up, would the desktop just discard the session state if any monitor is not available? Would it discard restore states only for applications on monitors that were disconnected or modified? Would it try to modify the state to move the windows around so it works on existing monitors, potentially having to move and resize windows automatically? Would it show a dialog or notification explaining to the user what is happening? Would it ask for a choice of what to do?
Because the app can run its own process namespace, which makes it much easier for CRIU to work.
CRIU only works well with pieces that are part of the same container. For stateful connections to other processes outside the container (e.g. the display server) there is no way to resume the connection without cooperation from the external process, or without some kind of re-implementation of that protocol. There is some information here that is also relevant to wayland: X applications - CRIU
You may test this extension -
No overview at start-up - GNOME Shell Extensions
I’d recommend a name that makes it clear this is no overview at startup, not something that removes the overview entirely.
I think it’s already clear?
Sure, if you read the description, but not if you just see the name, which is likely in lists. I mean, it’s your thing so do what you want… just a suggestion that I think will help people find it more easily.
I’m aware of [40] Session remains in Overview even if apps are automatically started (#3854) · Issues · GNOME / gnome-shell · GitLab but I’m afraid waiting on that could be a case of the perfect being enemy of the good. A simple flag to toggle it should cover quite a few scenarios.
For those of us who are auto-starting applications and running in kiosk-like situations (example: I run GNOME on a little machine that’s hooked up to my TV that launches a media player on startup, which is normally controlled via an IR Remote control) it would be nice to have a way to revert to the old behavior without resorting to third party extensions.
You do realize, this is of course, completely subjective. In addition, every desktop on the market from Microsoft to Apple and Linux takes the user straight to the desktop. I would say people are well used to it. A simple option for a major change that takes into account uses such as Kiosks etc would not be problematic.
Yes I agree, many options can be a bad thing, however, this is a rather major change from all other desktops and I believe it would warrant that.
The extension helps (better than nothing) but it still is ugly to have “overview” be displayed first and then disappear automatically.
My usual workflow is that I have all applications, that I need for my work, in autostart. So up to GNOME 40 my desktop started right into a state where all my applications are ready to go.
Now my applications still start up as desired but I have to hit “Esc” once after logging in.
Again: The extension helps, but I would really prefer to have some built-in config (maybe even accessible via “Tweak Tool”) to get the old behaviour back as I usually don’t start my applications from “overview”.
Here I give you my use case. My job is highly dependent on terminal operation. Therefore, I set my favorite terminal application to auto-start after the desktop is launched so that I could work immediately after I enter Gnome. But now I have to use super key or enter key to focus on it before working. One more key keystroke, much inconvenience.
Would you please suggest me a solution that don’t need install extensions?
why? … because i wanted to be greeted by my desktop wallpaper
please add the option to disable this.
… and some do use some task bars extensions like DtD, DtP or BaBar (advertising) (this one working with GS 40 :-p ) that make the overview almost useless.
Ok, I agree that’s not nice-looking (but handy anyway).
I think I’ve found simpler and it avoids this show-hide bad visual.
Could anyone here replace the Extension class in no-overview@fthx/extensions.js by this one and test?
class Extension {
constructor() {
Main.sessionMode.hasOverview = false;
}
enable() {
}
disable() {
}
}
@fmuellner does setting Main.sessionMode.hasOverview = false has downsides I did not see? Thanks!
I’ll add to recover the value after disabling, if it’s ok yet.