GNOME Bugzilla – Bug 709064
flicker of content from other workspaces when closing last window
Last modified: 2014-02-28 10:17:06 UTC
Since upgrading to 3.10: When I close the last window on an otherwise-empty workspace, I briefly see the contents of other workspaces flicker onto the screen before I (correctly) see the empty desktop.
Created attachment 256050 [details] Screencast of the issue
*** Bug 708842 has been marked as a duplicate of this bug. ***
Created attachment 256219 [details] [review] windowManager: Activate new workspace before removing the current one When removing the current workspace, the active workspace is changed to the preceding one automatically before we change explicitly to the last workspace. There is no good reason to change workspaces twice in this case, we can avoid the first one just by changing to the new workspace before removing any workspaces. I'm not quite sure why, but this change appears to make the block-animations code that is already there work reliably.
Created attachment 256220 [details] [review] windowManager: Don't remove the active workspace Currently workspaces (except for the last one) are removed when they become empty. While we do have special treatment for the case where the currently active workspace is removed, we just move directly without animations to the last workspace to avoid ending up on a "random" workspace. However this behavior is still a bit confusing, so keep the workspace around instead until the user decides to move to another one. Here is an alternative approach that changes the behavior of workspace removal which happens to fix this issue as a side effect. Obviously needs design review ...
*** Bug 709295 has been marked as a duplicate of this bug. ***
This would be a nice polish fix for 3.10.1
*** Bug 710660 has been marked as a duplicate of this bug. ***
*** Bug 715072 has been marked as a duplicate of this bug. ***
*** Bug 715153 has been marked as a duplicate of this bug. ***
*** Bug 720018 has been marked as a duplicate of this bug. ***
The second patch would be very welcome, as I agree it is quite confusing to be moved to the last workspace after we close the last window of a workspace.
*** Bug 720889 has been marked as a duplicate of this bug. ***
Any plan to merge to patches upstream?
There's two solutions, but we need design review to determine which one to push.
*** Bug 721133 has been marked as a duplicate of this bug. ***
*** Bug 723984 has been marked as a duplicate of this bug. ***
Comment on attachment 256219 [details] [review] windowManager: Activate new workspace before removing the current one Attachment 256219 [details] pushed as 0dab133 - windowManager: Activate new workspace before removing the current one
Attachment 256220 [details] pushed as 2631f03 - windowManager: Don't remove the active workspace (That's the approach the designer's preferred, but as it changes behavior, I pushed the alternative to 3-10).
(In reply to comment #18) > Attachment 256220 [details] pushed as 2631f03 - windowManager: Don't remove the active > workspace > > (That's the approach the designer's preferred, but as it changes behavior, I IMHO that solution is what should be done. It's way more intuitive
(In reply to comment #19) > (In reply to comment #18) > > Attachment 256220 [details] [details] pushed as 2631f03 - windowManager: Don't remove the active > > workspace > > > > (That's the approach the designer's preferred, but as it changes behavior, I > > IMHO that solution is what should be done. It's way more intuitive As an example: I run Eclipse on the workspace and have my gitk and git gui and terminal on a different workspace, the one below. When I restart Eclipse, it goes away, the workspace is removed, Eclipse comes up again, and now Eclipse is on the workspace below the git tools instead of above it. Very very annoying... This is but 1 example. I strongly believe that the active workspace should never be removed (or reordered for that matter)
(In reply to comment #19) > (In reply to comment #18) > > (That's the approach the designer's preferred, but as it changes behavior, I > > IMHO that solution is what should be done. It's way more intuitive Yes, and it's the solution that got committed to master (the upcoming 3.12). The other patch was just pushed to the stable branch, as changing behavior of a stable version shortly before the next one will be released is a bit questionable.
(In reply to comment #21) > (In reply to comment #19) > > (In reply to comment #18) > > > (That's the approach the designer's preferred, but as it changes behavior, I > > > > IMHO that solution is what should be done. It's way more intuitive > > Yes, and it's the solution that got committed to master (the upcoming 3.12). > The other patch was just pushed to the stable branch, as changing behavior of a > stable version shortly before the next one will be released is a bit > questionable. So 3.12 will have the behaviour I described in comment 20? That will be awesome! Thanks!
(In reply to comment #22) > So 3.12 will have the behaviour I described in comment 20? Yes, in 3.12 an empty workspace will only be removed once you move away from it (e.g. never when it is active)
*** Bug 725387 has been marked as a duplicate of this bug. ***