* Workspace Swipe: Refactor update and end functions
* Touch: Implement workspace swipe better
ignoring additional fingers and new touches
allow gaps-right and gaps-left to be different
* animation: Refactor AnimatedVariable
This commit decomposes the AnimatedVariable class into a base class
with the common attribute to all variable types and a templated derived
type containing strongly typed info on the type being animated.
Access to the typed version is perfomed using the visitor pattern. A
utility is provided to build a visitor on the fly using lambdas.
Adding a new type to be animated should just be a matter of adding the
typed in the list defined by the ANIMABLE_TYPES macro
The size of the commit is justified by the API change in the
AnimatedVariable class. No more vec(), fl() or col() method but a unified
value() method.
* animation: Remove visitor pattern
* animation: Fix coding style
* animation: Fix coding style
When workspace_swipe_use_r is enabled, swiping from WS 1 to a non-empty WS 2 would
hide WS 1 (Similar effect to issue #4076). This is caused by a faulty
check which doesn't consider, that workspaceIDLeft could be the current
workspace.
This bug is only a problem for r, because m wraps around on WS 1 m-1, whereas r stays on WS 1.
The previous code could run into issues into the following circumstances:
* The focused monitor is on its rightmost workspace with ID `i`.
* Another monitor has a workspace with ID `i+1`.
* `workspace_swipe_create_new` is enabled.
Then, swiping rightwards attempts to target a new workspace with ID
`i+1`: completing the swipe gesture unintentionally focuses that
workspace on whichever monitor it's already on while leaving the active
monitor in a broken state where it shows no windows but creates new
windows on the workspace it was previously on; and cancelling the swipe
gesture shifts the entire workspace `i+1` to the right by the width of
the active monitor.
By choosing an ID that doesn't exist, this problematic behavior is
avoided. More specifically, it's the smallest ID greater than any
existing workspace's ID, because otherwise the new workspace that was
seemingly just created to the right of the rightmost workspace could end
up somewhere in the middle of the workspace order.
