af543daf1c
Animating the window clones of the overview requires the fullGeometry and the actualGeometry to be set, which they won't be when showing the overview for the first time. So don't even try to animate the window clones in that case because the geometries will still be null and accessing them in workspace.js will throw errors. The workspace views will still get the correct layout as soon as the allocations happen because syncing the geometries will trigger updating the window positions. Since animations are disabled for position changes when syncing the geometry though, we won't get an animation and the clones will jump into place. That's not a regression though since before this change we also didn't animate in that case because the geometries used were simply wrong (the actualGeometry was 0-sized as explained in the last commit). If we wanted to fix the initial animation of the overview, we'd have to always enable animations of the window clones when syncing geometries, but that would break the animation of the workspace when hovering the workspaceThumbnail slider, because right now those animations are "glued together" using the actualGeometry, so they would get out of sync. The reason there are no errors happening in workspace.js with the existing code is that due to a bug in Clutter the fullGeometry of WorkspacesDisplay gets set very early while mapping the WorkspacesViews (because the overviews ControlsManager gets an allocation during the resource scale calculation of a ClutterClone, see https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1181), so it won't be set to null anymore when calling WorkspacesView.animateToOverview(). https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1119 |
||
|---|---|---|
| .. | ||
| dbusServices | ||
| gdm | ||
| misc | ||
| perf | ||
| portalHelper | ||
| ui | ||
| js-resources.gresource.xml | ||
| meson.build | ||
| portal-resources.gresource.xml | ||