Combine sequential mouse movement events

[nyanpasu64]

Previously on Linux (not Windows), if you opened Klystrack and dragged with a high polling rate mouse, the program would lag processing SDL_MOUSEMOTION events and redrawing the screen (#299). This fixes the bug.

Note that this PR changes the submodule to point to a commit that only exists in my fork (https://github.com/nyanpasu64/klystron/tree/fix-high-refresh-mouse), and pulls in changes from klystron on top of my own changes. To my current understanding, I'd merge the klystron changes, then change this PR to point to the merge or cherry-pick commit (unless you know a better way).

Fixes #299.

[nyanpasu64]

Anyway I've been told the "proper" fix is to not render a new frame on every mouse movement, not to merge "similar" mouse updates together (but still wait a frame every time you press or release the cursor). Unfortunately that might be a bigger change to the event loop than this PR (IDK, I didn't look into exactly what needs to be changed), and I don't plan to work on that right now.

[kometbomb]

Did you check if the FX tab works fine after this? The delay taps can be dragged and I remember those are a bit finicky to get synced with the mouse movement.

[nyanpasu64]

I'm actually new to klystrack and don't have any real experience with the program. Nonetheless dragging the delay taps does seem to work right. Interestingly, dragging the background moves the active delay tap rather than deselecting it; is this intentional?

However I have noticed some janky mouse behavior that persists across Windows without this change, Linux with lag, and Linux with my lag fix:

• Clicking the Menu button opens the menu bar, but doesn't open the File menu until you move your mouse.
  • Clicking a second time makes the menu bar vanish. At first I couldn't figure out how to open the File menu at all, thinking I had to click on a submenu, but the menu bar vanished when I tried clicking File.
  • The top 2 pixels of the menu bar does not expand or switch submenus. Before figuring this out, I thought that submenus would intermittently fail to be opened, or if I moved my mouse out of Klystrack, to a different submenu, and back into Klystrack. Even after I realized the top two pixels of the menu bar are ignored, I still got tripped up from time to time.
• In the file browser, it seems that clicking and dragging or holding a file (for over 0.5 seconds or so) acts like double-clicking it. Is this deliberate?

https://www.youtube.com/watch?v=7a1xCkPPabM RIP annotations... seems https://invidious.snopyta.org/embed/7a1xCkPPabM?iv_load_policy=1 still works

[kometbomb]

Not sure if the tap deselection when clicking should be there but I wouldn't be surprised if it wasn't.

The double clicking thing comes from the fact the mouse click implements a kind of keyrepeat just like the keyboard. You can then hold the mouse button down to change some value (it receives multiple separate click events).

[nyanpasu64]

A few more things:

• When the window is unfocused, the first click is discarded on Windows and Linux. I did not expect this to happen, and this is not standard behavior on either OS. (In native macOS apps, I get inconsistent results, like clicking a Finder window sometimes switching the focused file.)
  • I recall clicking the bottom-right mode buttons switching to different tabs on the first click (focusing the window) and second click. Maybe I imagined it happening; I can no longer reproduce anything other than "no effect" on the first click.

[nyanpasu64]

I think one disadvantage of this change is that when I open a menu and move the mouse quickly up and down over other menu items, it won't reliably open them (whereas GTK and Qt apps do). It also doesn't help that Klystrack's menu items are so short vertically.