Fix startup animation #2166
Fix startup animation #2166
Conversation
Because gnome-shell stopped exporting the value in 45.0 it was being treated as undefined, and therefore we had no startup animation.
vanvugt
force-pushed
the
fix-startup-animation
branch
from
e1a9e17
to
a789660
Compare
Rather than trying to duplicate it. And when the upstream animation is done we can run our own slide-in animation. Closes: https://bugs.launchpad.net/bugs/2058468 Closes: micheleg#2110
vanvugt
force-pushed
the
fix-startup-animation
branch
from
a789660
to
b7f52f7
Compare
|
Tested on both GNOME 46 and 45, which conveniently are the only versions we have to support now. |
| if (Main.layoutManager._startingUp && Main.layoutManager._waitLoaded) { | ||
| // Disable this on versions that will include: | ||
| // https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2763 | ||
| this._methodInjections.addWithLabel(Labels.STARTUP_ANIMATION, | ||
| Main.layoutManager.constructor.prototype, | ||
| '_prepareStartupAnimation', function (originalMethod, ...args) { | ||
| /* eslint-disable no-invalid-this */ | ||
| const dockManager = DockManager.getDefault(); | ||
| const temporaryInjections = new Utils.InjectionsHandler( | ||
| dockManager); | ||
|
|
||
| const waitLoadedHandlingMonitors = (_, bgManager) => { | ||
| return new Promise((resolve, reject) => { | ||
| const connections = new Utils.GlobalSignalsHandler( | ||
| dockManager); | ||
| connections.add(bgManager, 'loaded', () => { | ||
| connections.destroy(); | ||
| resolve(); | ||
| }); | ||
|
|
||
| connections.add(Utils.getMonitorManager(), 'monitors-changed', () => { | ||
| connections.destroy(); | ||
|
|
||
| reject(new GLib.Error(Gio.IOErrorEnum, | ||
| Gio.IOErrorEnum.CANCELLED, 'Loading was cancelled')); | ||
| }); | ||
| }); | ||
| }; |
There was a problem hiding this comment.
Ideally I'd be very happy to drop all this code, but one reason for that was that https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2763 was still a thing at the time.
I've not tested anymore the script, but that was triggering the same root issue we had that was leading to a black/non-responsive screen input area.
So, have you tested with tricks like those and see if we're strong enough now?
There was a problem hiding this comment.
I don't remember all the details of those clipping bugs, only that it happened twice in the past. So we should investigate, but I am keen to build on a much smaller code base if any new fix is required. I vaguely recall finding upstream had the same bug, so that plus the fact that we no longer modify the upstream animation, should mean any fix required for the clipping issue could go upstream.
There was a problem hiding this comment.
Sorry for the delay...
The X11 VM clipping bug does still happen upstream (no extensions), but only for logging into Main.sessionMode.hasOverview == false which is not the default. And the clipping gets corrected at the end of the login animation.
dash-to-dock master does not have the bug, but to test that you also need to fix the undefined STARTUP_ANIMATION_TIME issue or else there's no way to slow down animations.
dash-to-dock #2166 does have the bug, but it now corrects itself at the end of the login animation just like upstream does.
So we no longer need to carry the clipping fix here. The bug is now the same with or without extensions after this PR. It should be treated as an upstream bug (when Main.sessionMode.hasOverview == false) from now on.
There was a problem hiding this comment.
So I checked the script and the bug is back... mhmh
There was a problem hiding this comment.
Yeah that's kind of what I said in the last two paragraphs. I think it's OK. It recovers at the end of the animation and the same bug occurs without extensions so any fix should go in upstream gnome-shell.
STARTUP_ANIMATION_TIMEnon-zero again.Closes: #2110 and https://bugs.launchpad.net/bugs/2058468