From e4db68a1da4288d4ceb2c8d0f3cbc524db02f7b5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jonas=20Dre=C3=9Fler?= Date: Thu, 12 Mar 2020 13:43:07 +0100 Subject: [PATCH] Revert "workspacesView: Work around spurious allocation changes" We now found the underlying bug: The ControlsManager (which causes the bad call to `_updateWorkspacesFullGeometry()`) is getting (re-)allocated while we add the view to the overviewGroup actor because the overviewGroup is already visible and the view is immediately getting mapped by `clutter_actor_add_child_internal()`. That causes a resource-scale calculation and that indirectly causes a call to `_clutter_stage_maybe_relayout()` (explained more detailed in the last commit). So now that we got rid of the immediate relayout happening when mapping the view, we can revert this fix. This reverts commit 6cc19ee6f05102baef39b8a1bec73eff06699879. https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1315 --- js/ui/workspacesView.js | 5 ----- 1 file changed, 5 deletions(-) diff --git a/js/ui/workspacesView.js b/js/ui/workspacesView.js index a4ed18d48..cc0d4f24b 100644 --- a/js/ui/workspacesView.js +++ b/js/ui/workspacesView.js @@ -691,15 +691,10 @@ class WorkspacesDisplay extends St.Widget { else view = new WorkspacesView(i, this._scrollAdjustment); - // HACK: Avoid spurious allocation changes while updating views - view.hide(); - this._workspacesViews.push(view); Main.layoutManager.overviewGroup.add_actor(view); } - this._workspacesViews.forEach(v => v.show()); - if (this._fullGeometry) this._syncWorkspacesFullGeometry(); if (this._actualGeometry)