GNOME Bugzilla – Bug 649001
weird workspace switching edge cases
Last modified: 2011-06-03 17:58:42 UTC
It's possible to get 3 different behaviours by doing the same thing three times in a row. Open a single window. You now have two workspaces -- the first one (with the window) and the empty one. Switch to the empty one. Enter the overview and hover the workspace switcher to have it slide out. Drag the window from the first workspace to the empty workspace. Do this 3 times. The first time, the window moves from its old workspace onto the empty workspace (which is the present workspace). This causes you to see it in the overview. Totally expected. The first workspace is gone so it disappears causing the present workspace to slide up. The present workspace is no longer empty so a new workspace is created. Absolutely perfect. The second time, the workspaces shift in the expected order but somehow the focus ends up on the newly created workspace (with no windows) instead of the workspace that I just dragged the window to. That's pretty weird, but still vaguely understandable. Probably a bug, I think. The third time, since it's the empty workspace with focus again, things proceed in exactly the same way as they did the first time. At the end of it, however, I don't see the window in the overview (even though it is on the present workspace and visible in the thumbnail in the workspace switcher). Moving the mouse away from the workspace switcher causes the window to appear in the overview. That's surely a bug. So I guess there are actually two issues here: 1) When moving a window from the currently focused workspace to another workspace, causing the currently focused workspace to become empty then we should change focus to the workspace that the window was moved to instead of to the empty workspace. 2) (while hovering the workspace stack) having a workspace created and focused and then moving a window to that workspace results in the window not being shown in the overview. Unhovering the workspaces at any point in this process is enough to cause the bug not to happen.
*** Bug 645731 has been marked as a duplicate of this bug. ***
Created attachment 189010 [details] [review] workspaces-view: Set geometry on new workspaces Currently the workspace geometry is updated on zoom/allocation changes, which means that newly added workspaces use their initial geometry of (0, 0, 0, 0) until the next zoom change. As a result, windows on the affected workspaces are mispositioned, e.g. placed outside the workspace area. To fix, set the geometry on newly added workspaces to the view's cached values. Also fixes a bunch of warnings about trying to set properties to illegal values (e.g. negative scale/width/height/...).
(In reply to comment #1) > *** Bug 645731 has been marked as a duplicate of this bug. *** How can an _earlier_ bug be a duplicate of a _later_ bug?
Logically, if two bugs are duplicates, any of the two is the duplicate of the other... ;-) Sometimes it happens developers start working on a more recent report because they didn't have the older one offhand, or didn't know about it. Then, it makes sense to mark the older one duplicate of the newer instead of the reverse, because useful discussion and patches have gone there. That doesn't mean your report isn't worth the other, that's just a consequence of chance. At the end of the day, the goal is to fix bugs, which is the case here - not to book keep them for as long as possible!
Comment on attachment 189010 [details] [review] workspaces-view: Set geometry on new workspaces makes sense, fixes the warnings
Attachment 189010 [details] pushed as 2021edd - workspaces-view: Set geometry on new workspaces