I think it’s already clear?
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
I’m aware of https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/3854 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.
3 Likes
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.
1 Like
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”.
2 Likes
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.
1 Like
… 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.
It depends. It does what it says on the tin, that is, it disables the overview altogether. For the users who are only asking for not logging into the overview, that’s quite a downside.
Then you are lucky and the hasOverview change happens after the session-updated handler that updates the overview.
Try after locking the screen …
Well, after resuming from lock, it does not block the overview either…
I must say I did test that before posting the test-code here
Ah right, I see why that is working. Still, that’s very much incidental, so you don’t get to complain if something breaks in a future update.
One thing I see that will be broken are the super+number shortcuts to activate a dash icon (until the screen is locked, which should reset hasOverview to the “correct” value again)
Ok, let’s try this. For users, the legacy code still is commented out in extension.js. I’ll revert this new version if it turns to show hidden side effects bugs. Florian, I included a timeout to restore hasOverview to true, to avoid keeping this fake value to false.
This is the safest and most correct version I can think of off-hand:
class Extension {
constructor() {
this._realHasOverview = Main.sessionMode.hasOverview;
}
enable() {
if (!Main.layoutManager._startingUp)
return;
Main.sessionMode.hasOverview = false;
Main.layoutManager.connect('startup-complete',
() => (Main.sessionMode.hasOverview = this._realHasOverview));
}
disable() {
Main.sessionMode.hasOverview = this._realHasOverview;
}
}
It doesn’t do anything when enabled inside the session (rather than during startup), and resets the session mode value to the original after the startup animation (instead of after an arbitrary timeout).
1 Like
Ok thanks!
https://extensions.gnome.org/review/24054
I tested this and did not have any issue nor message in logs. The hasOverview value is restored. So, let’s go for it.
Do you know a way to know if gnome is cold starting vs back from sleep vs back from screen-lock?
No really.
From an extension, Main.layoutManager._startingUp can be used to determine whether it is enabled before any user interaction is possible (that is, as part of the session startup).
Assuming a logind system, LoginManager's prepare-for-sleep signal has an aboutToSuspend parameter that indicates whether the computer is going to (true) or coming back from sleep (false).
But there’s not really a way to differentiate from an extension whether it is enabled explicitly by the user (installing via the website, toggling in Extensions/Tweaks) or automatically by gnome-shell on unlock.
1 Like
Thank you for the extension and collaboration on proper implementation of it. My thought process behind {topic} is not technical, it’s psychological. When I log in, I want a brief moment of peace to sip my coffee. see my background, take a deep breath, then decide when I want to take that first action for work for the day. I don’t need my OS telling me when I log in that “You must do something immediately!”.