GNOME 40 login is to the activities/overview mode, how do you disable this?

It’s not one time, and it’s also the wrong tool.

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.

2 Likes

I’m happy whatever works for GNOME.

Let’s wait for the GNOME 40 release, and see if the efforts have paid off.

Thanks!

The easiest way to avoid ending up in the overview after login is to no log out in the first place.

Locking the screen or suspending your laptop are two convenient ways of doing so.

2 Likes

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!)

2 Likes

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.

2 Likes

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.

1 Like

Not without collaboration from applications, no.

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.

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:

  • who saves what state, and where?
  • what happens with app and OS upgrades in between a save and a restore?
  • what happens when the geometry of the monitors change?

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” :slight_smile:

2 Likes

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: https://criu.org/X_applications

You may test this extension -
https://extensions.gnome.org/extension/4099/no-overview/

1 Like

I’d recommend a name that makes it clear this is no overview at startup, not something that removes the overview entirely.

1 Like

I think it’s already clear?

image

1 Like

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.

1 Like