Capture mouse when click+dragging input fields (AD, AP, APUB desktop)

[aXu_AP]

Hi everybody! I've been using Affinity Suite for a few weeks now and I'm enjoying it - keep up good work! I figured out I'd share one thing that I think would improve usability: When changing numeric values by dragging from label, the mouse hits often the edge of screen and values can't be taken further. This problem is especially pronounced if input field is closer to the edge of screen but for bigger changes even from the center I feel to hit the edge quite fast. See the screen capture below:

There's 3 ways of countering this problem that I'm aware of (listing by preferred first):

1. Capture and hide the mouse for the time of dragging. After releasing the mouse, the cursor will be at the same place it started. Implementation example: Godot editor (a game engine) does it like this, and it's very intuitive. Since while dragging, your eyes are following the input value, not the cursor, it makes sense to place the cursor where you left it (at the spot eyes are already looking).
2. Wrap the cursor position around the screen edges. If cursor goes over the edge, return it to the other edge allowing for continuing in the same direction. Implementation example: Blender (3D software) has this feature. It works well, altough it's easy to lose track of where the mouse is after dragging.
3. Adjust the speed of the change (note: I'm aware of modifier key to increase speed, but it goes in 10x bigger increments, losing precision). Implementation example: Photoshop does have quite good range so this problem rarely comes up - altough it doesn't entirely address it.

I know there's the 1 suggestion per thread rule, but since these are mutually exclusive I figured out it should be in the same thread. Moreover, options 2 and 3 are just alternatives to discuss about, but IMO the best one is the option 1.

As a related side note (and partly the root of the issue): I'm not sure if this is intented behavior or a bug, but it seems that the speed of the mouse is ignored/incorrectly evaluated when moving the mouse - as if only the direction of motion is used to decide the delta for the input. So if I want to make a big difference and consequently move the mouse faster, I hit the edge sooner and end up in the situation above. Ironically moving mouse slower will get you further, but this is unintuitive and differs from any other program I've used. If this a bug, I can file a separate bug report.

Edited April 17, 2024 by aXu_AP
Clarifying the title and the options