You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* The default implementation will attempt to parse the args (and assert fail if it failed),
42
42
* and then enqueue the param changes to the guiToProcQueue, for the host and audio side to pick up.
43
43
*
44
+
* For what I've been calling "ouroborosing" the cursor position, and generally providing the facilities to hide the cursor, snap back to original mouse down position on a drag etc, we also provide some extra helpers here.
45
+
* `beginScopedCursorMoveGesture()` caches the mouse down position at the time of calling, and hides the cursor.
46
+
* `endScopedCursorMoveGesture()` restores the cached cursor position, and shows the cursor. These functions should be called as a pair,
47
+
* for a slider in mouseDown / mouseUp for example.
48
+
*
49
+
* `resetCursorPosition()` does much the same as `endScopedCursorMoveGesture()`, except it doesn't zero any of the internally cached variables, and doesn't show the cursor.
50
+
* The use case is quite different, and is for forcing the cursor to be within a given area - this allows for "infinite drag", or "ouroborosing" without the cursor hitting the screen edges.
51
+
* If `resetCursorPosition()` is used, then to avoid unexpected jumps, use `tickCursorMove()`, and use its return value instead of the js side `event.movementY` variable.
52
+
* It updates the internal cache of the last mouse position, and then returns the difference between the old and new values. Call it every time `mousemove` is called for example.
53
+
* `clearPreviousCursorPosition()` in this paradigm should be called on mouseUp, and simply nulls the last mouse position stored in the cache, preparing it for a new gesture.
54
+
*
55
+
*
44
56
*
45
57
* The structure of an event in the default implementation is:
// Note that while this doesn't generate an event, its delta will be added to the next mouse event that *does* generate an event - so in effect, this can cause a massive fucking jump -
84
+
// If you can intercept the next event, this is workaroundable - see WebviewEditor's ouroboros stuff
0 commit comments