Asking the people that use GNOME what to change about GNOME will either yield a list of bugs to be fixed, or a “don’t change anything” result.
The current design and development of the Shell has been going through multiple user studies; we need more of those, over the span of months and years, not pointless one-off surveys.
We also need more designers and more developers to iterate over the UX, of course. What we do not need is adding escape hatches and unmaintainable options to let people “sit one out” every time something changes.
Yeah, but since we ask people to reboot to apply updates, reboots are still gonna happen. (And even if we make updates less frequent, as a user, updates are often good — fixed bugs, new features!)
Only system updates, of course, as app updates don’t require rebooting.
In any case, the “drop people on an empty desktop” approach has been a point of contention for a while; I still remember user testing done 5-6 years ago at Endless, with people not really understanding how to launch applications with GNOME; people were familiar with phone/tablet launchers, and even with Windows and its big “start here” button.
Showing the applications grid was one of the first changes Endless made at the time, and it was pretty clear in multiple cases that it helped people moving forward with what they wanted to do with their computers.
Not everyone has a Zen-like predisposition to an empty initial state.
Of course, the pendulum swings, and some people are upset; but before using the five most terrifying words in free software (“just make it an option”) maybe we can iterate a bit, and try to see if this change does improve things.
They do on a lot of systems still, including most Fedora Workstation users — a group of people who will be seeing this in a production-release operating system reallllly realllly soon now. And, for better or worse, we also live in a world where pretty significant system updates are a regular occurrence.
I personally think the change to a “ready to act!” start is good, and probably won’t shock people too much, but I also want to be really sensitive to the feedback we’re getting. I am also feeling some pain when restarting (not with this but with workspace setup), and think this is an area we could definitely improve.
For example, if Firefox was previously running when the system was last shut down, GNOME Shell could restart it and put its windows back where they were. (And Firefox itself will try its best to take care of putting the content back where it was.)
And perhaps over time as more apps become more robust in this way, they could also do the same. I have a dream that Flatpaks could — on intentional shutdown and also periodically — use CRIO and come back right where they were.
In this case, Overview would only come up on login if you are truly starting a fresh session.
gnome-shell only has code to match windows to the corresponding app, but it doesn’t know that window 0x123456 is “the same” window as window 0x654321 in a previous session.
It knows how to launch an application, but not how to tell an application that it should open n windows that match a previous session.
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.)
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.
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?
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: https://criu.org/X_applications
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.