implement slowdown for animation speed

[Ind-E]

Hey!
I saw this project in a discussion on niri's github and wanted to try it out.
When I tested it on my laptop, I found that the workspace switching animation didn't line up because I have a faster animation speed set in niri's config.

This PR adds a new config setting for animation slowdown, mirroring the setting in niri. I'm not very experienced with knuffel, so feedback is appreciated (also feel free to change the config structure, I don't know if an animation section makes sense).

also, you should use cargo fmt on your code to make it more consistent and readable, and avoid very long lines.

[PandorasFox]

oh, thank you! I'd been loathe to tackle this myself yet - ideally, I want to be able to get all of the animation config from niri directly (& know when that changes from the ipc stream), but that's not presently possible, so I'd held off on this. I think implementing just the slowdown factor is a reasonable middle ground, though :)

you should use cargo fmt on your code

sorryyyy i will get to that momentarily. I'm guilty of being an ultrawide user and do need to set up at least format-on-commit. I've been holding off on that since I'm still changing some of the internal interfaces / state divisions somewhat frequently and wasn't expecting anyone else to look at this yet 😅

[PandorasFox]

oh, as for the actual config bit, I think that it's reasonable to implement it that way - missing a default value of 1.0, though; I'll address in a conflict resolution since I just implemented output state restoration on replug and shuffled some state divisions around.

[Ind-E]

Since we don't when/if niri ipc will expose animation information, would you consider reading from the niri config file?

Although I will mention having independent animation speeds would still be a reasonable use case. When experimenting, I found setting the slowdown to something much higher, like 10, gave an interesting effect.

[PandorasFox]

I did consider reading the niri config file; I'm not really sure where that would best sit. My ideal niri ipc interface would involve receiving specific animation params (like scroll initial velocity for trackpad users, or more granular scroll position changes for trackpad users again), which would sidestep a lot of the issues here, I think.

I'll think some on how to best handle independent animation timescales. Mostly, I haven't (and won't for a hot minute) gotten around to alternate position interpolation animations since I use the niri default and it shouldn't be too hard to build out a set of enums & match statements in the scroll position callbacks.

I assume that just an animation curve per-render-mode would be reasonable? e.g. every (base render mode, workspace-trigger) category could have its own animation configured there - my philosophy has been that I'm loathe to enter the world of "having to copy a value out of the niri config and splice it into the pandora config", but for now I think "non-default users can be trusted to handle copying over animation settings" :)

[PandorasFox]

all feedback around this is very welcome btw, and thank you for the pr :)

[PandorasFox]

This has gotten me thinking about how to animate 2d scrolling, though, and I have some pretty good ideas now - I think that having each render mode have animation sub-settings makes the most sense.

The 2d scrolling is likely going to use a much 'tighter' spring along the vertical axis and a much 'looser' spring along the horizontal axis, so that debouncing the horizontal position across workspace changes is smoother. Either way, I'll probably want to play with those config values there to help me decide on some default values involved there, but I might take a poke at all this soonish - I'm going to go rewrite the scroll position model to just be a percentage finally