GNOME Bugzilla – Bug 771536
Some more cycle-* fixes
Last modified: 2016-09-18 09:03:56 UTC
The new cycler UI introduced in commit 3171819c has issues with hidden windows (that is, minimized or on a different workspace). The most pressing issue is that we leave window actors visible after cycling through them, so we end up with "ghost" windows hanging around after the operation finishes. The first two patches fix that, and I think we should get a freeze break for them. The other two patches are more cosmetic in that they "only" fix some visual glitches with the animations at the end of the operation. I'd still like to see them get in, but it wouldn't be that much of a deal to defer them to 3.22.1 ... (they are also more involved than the straight-forward visibility fix)
Created attachment 335706 [details] [review] window-actor: Make sync_visibility() public When we mess with a window actor's visibility from the shell side (yes, I know :-( ), we should at least restore the proper visibility when we're done with it ...
Created attachment 335707 [details] [review] altTab: Restore correct visibility when cycling windows Commit 3171819c improved window cycling by using a dedicated to clone for highlighting rather than activating all cycled windows. Original window actors are hidden while its clone is showing, and shown again afterwards, however the latter is wrong for actors that are not supposed to be visible (for example where the window is minimized, or on a different workspace). Fix this by properly syncing the actor's visibility instead of showing it unconditionally.
Created attachment 335708 [details] [review] altTab: Improve cycling to a window on another workspace Both 'cycle-group' and 'cycle-window' shortcuts allow cycling through windows on all workspaces. While this works, it looks quite broken since we started showing clones for highlighting: the selected window vanishes (when its clone is destroyed), then slides back in with its workspace. Instead, slide the selected window to its workspace like we do for the 'move-to-workspace-*' shortcuts.
Created attachment 335709 [details] [review] altTab: Skip unminimize effect when cycling to a window Similar to windows on another workspace, selecting a minimized window doesn't look quite right - the selected window disappears, then animates back in. Fix this by adding support for skipping the next effect to the wm and use it to bypass the unminimize animation.
Review of attachment 335706 [details] [review]: ok
Review of attachment 335707 [details] [review]: oops, looks good
Review of attachment 335709 [details] [review]: looks fine
Review of attachment 335708 [details] [review]: code looks good but cycle-window doesn't allow cycling to windows on other workspaces here. you might want to double check that and change the commit message
(In reply to Rui Matos from comment #8) > code looks good but cycle-window doesn't allow cycling to windows on other > workspaces here. It doesn't by default, but it follows the org.gnome.shell.window-switcher current-workspace-only setting ...
Comment on attachment 335706 [details] [review] window-actor: Make sync_visibility() public Attachment 335706 [details] pushed as 9e54914 - window-actor: Make sync_visibility() public
Attachment 335707 [details] pushed as d6a78d6 - altTab: Restore correct visibility when cycling windows Attachment 335708 [details] pushed as a029a35 - altTab: Improve cycling to a window on another workspace Attachment 335709 [details] pushed as becd29c - altTab: Skip unminimize effect when cycling to a window