feat: movemouse-speed

[ArijanJ]

Closes #488
Adds a movemouse-speed <percentage> action which somewhat hackily makes the mouse go at a different speed, at runtime.
I did some dogfooding and I think the math checks out.

[ArijanJ]

I tried modifying distance instead, and while it works perfectly for movemouse, it's very wonky for movemouse-accel:

distance = *distance * (self.move_mouse_speed / 10) / 10,

Unfortunately copy-pasting this line for min and max_distance yields pretty weird results.

[rszyma]

This case that is not handled correctly:

1. press any movemouse-* action
2. press 1st movemouse-speed action
3. press 2st movemouse-speed action
4. release both movemouse-speed actions
5. the original movemouse-* action interval is different from the starting one and, until the key is released.

[rszyma]

movemouse-speed can increase movemouse-* interval above 65535 (u16 limit) which will cause panic

thread '<unnamed>' panicked at 'attempt to multiply with overflow', src/kanata/mod.rs:973:51

however it would require having absurdly high movemouse-* interval like 660 in and 1% in movemouse-speed

[ArijanJ]

Alright, I think the only thing left to do is to restore self.move_mouse_speed correctly on the MoveMouseAccel CustomEvent::Release event, which I'm not too sure can be done with the current math (right now it's self.move_mouse_speed = 100;, which is not correct in your case of pressing two movemouse-speed actions. A solution could be inserting the previous speed into a hashmap on the Press event, and then reverting that from the Release event with the speed argument as the key.

[rszyma]

A solution could be inserting the previous speed into a hashmap on the Press event, and then reverting that from the Release event with the speed argument as the key.

This is a decent idea, however I'd suggest to use a list instead of a hashmap. Hashmaps/sets can't have duplicate keys (assuming you wanted to use the hashmap as set) while we need to handle a case where 2 same values are added.

[ArijanJ]

This way makes tons more sense and gets rid of all the previous issues we had for free. I couldn't get it to panic at all through my limited testing, plus it isn't choppy anymore due to high interval values.

[rszyma]

Besides the comment above, this PR looks good to me now.

[ArijanJ]

I wonder if this should also apply to the scroll events?

[rszyma]

I agree with the idea of having a speed modifier for scroll, but I think it should be a separate action, because someone might have use case where they want only scroll or only mouse movement speed affected at a time.

[ArijanJ]

Yeah, although I don’t think that’s in the scope of this particular PR.

[jtroo]

Nearly there! Thanks for doing all of the revisions so far.

Only some minor textual suggestions for clarity/accuracy- can take them, leave them, or use different text for clarity.

Other than that, please fix the formatting with cargo fmt --all and fix the clippy errors.