GNOME Bugzilla – Bug 602598
WindowOverlay positions don't get updated when adding/removing workspaces in the overview
Last modified: 2009-12-18 16:28:03 UTC
This happens for instance when starting with the following setup of workspaces (notice that there is a space between the rows now): [1] [2] [5] [3] [4] [6] and with at least one window on any of the workspaces 3,4 or 6. If now a new workspace ([7]) is added, the existing workspaces don't get scaled and 3, 4 and 6 slide upwards (as expected) and 7 slides in: [1] [2] [5] [3] [4] [6] [7] So far everything is fine. But when the window overlays are shown again, window overlays of the windows on 3, 4 and 6 are still at the same position on the screen as before, and thus they appear somewhere below the windows they belong to.
Created attachment 148252 [details] [review] [workspaces] Reposition items at start of fade in We need to be set the positions after the animation ends (and fadeIn starts), not before when allocation is changed.
Review of attachment 148252 [details] [review]: Seems simple enough and certainly improves the current behavior - but the positioning still is not quite right (at least on my netbook). It might be worth resurrecting some code from Workspace and do the positioning there - I can look into it, so you can keep on working on some search-sugar ::: js/ui/workspaces.js @@ +373,2 @@ fadeIn: function() { + this._positionItems(); fadeIn() is called from a Tween onComplete handler, which may be run before completion ... @@ +396,3 @@ + let [x, y] = this._windowClone.actor.get_transformed_position(); + let [w, h] = this._windowClone.actor.get_transformed_size(); ... so size and position may be different from the ones the window ends up with.
Created attachment 148261 [details] [review] Reposition items at start of fade in We need to set the positions after the animation ends (and fadeIn starts), not before when allocation is changed. As the window may still be in motion when the overlay is repositioned, it is safer to pass the calculated values as parameters.
Review of attachment 148261 [details] [review]: Looks right. Though I wonder if we could have a state machine to handle out of order onComplete callbacks, and then just one callback which calls others when everything's settled down. But this seems fine for now.
pushed