Inhibit workspace animations when workspaces view is open #459
Conversation
Fixes pop-os/cosmic-workspaces-epoch#27. We want this to apply to changes to workspace either through keybindings or the cosmic-workspaces UI, so it adding a check here seems reasonable. In principle it could be good to have some kind of privileged protocol for setting things like this. We may also want a configuration option to disable animations at some point.
|
Unrelated to this specific change, I'm not sure exactly what the It does cause weird behavior if you call |
This can also be triggered with the other workspace switching methods: Super + ctrl + up/down same way in rapid succession Four finger swipe same direction in rapid succession |
| let layer_map = layer_map_for_output(&self.output); | ||
| let animate = !layer_map | ||
| .layers() | ||
| .any(|l| l.namespace() == WORKSPACE_OVERVIEW_NAMESPACE); |
There was a problem hiding this comment.
How weird is this interaction with the touchpad gestures? I imagine it feels quite bad when the workspace abruptly changes. We probably just want to disable the gestures for now, when the overview is active?
Yes that shouldn't reset the animation, but rather just change the target workspace, because I didn't want to implement an animation queue just yet. 😅
Yeah absolutely, I don't like hard-coding all these exceptions for the Lets first figure out, what the overview needs first though and then design a protocol. So short-term these kinda changes are totally fine for me. But the protocol could also help with excluding the view from rendering and possibly also letting cosmic-comp handle the background rendering. |
Fixes pop-os/cosmic-workspaces-epoch#27.
We want this to apply to changes to workspace either through keybindings or the cosmic-workspaces UI, so it adding a check here seems reasonable. In principle it could be good to have some kind of privileged protocol for setting things like this.
We may also want a configuration option to disable animations at some point.