Open ids1024 opened 2 months ago
Unrelated to this specific change, I'm not sure exactly what the else
condition in activate
is meant to help with.
It does cause weird behavior if you call super+<num>
twice in rapid succession, so it animates but then jumps back to the start of the animation.
It does cause weird behavior if you call
super+<num>
twice in rapid succession, so it animates but then jumps back to the start of the animation.
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
It does cause weird behavior if you call super+
twice in rapid succession, so it animates but then jumps back to the start of the animation.
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. :sweat_smile:
In principle it could be good to have some kind of privileged protocol for setting things like this.
Yeah absolutely, I don't like hard-coding all these exceptions for the app_id
. It might make an incentive for any alternative projects to re-use it.
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 https://github.com/pop-os/cosmic-workspaces-epoch/issues/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.