Clarification of "relative scrolling"?

[pythonian4000]

I am planning to migrate PyLeapMouse to using https://github.com/SavinaRoja/PyUserInput for all mouse functions, so it can handle the cross-platform support. Potentially this could make the code entirely OS-agnostic (as Leap.py is included in the SDK and could be linked to).

As part of this, I pointed the PyUserInput maintainer to the scrolling code in PyLeapMouse so they could add full cross-platform scrolling support (needed before a migration would be possible). They have a question that I am unable to answer, however:

I'm not terribly familiar with relative cursor scrolling, and what distinguishes it from absolute scrolling; could you provide me with a few brief statements of the motivation and uses of it? It should help me become educated on the subject faster.

Would you be able to explain how your relative scrolling code came into being? Either here (and I will copy across), or you could reply directly at https://github.com/SavinaRoja/PyUserInput/issues/10

[wyager]

Could you point me to exactly what you are talking about within PyLeapMouse? If you're looking at [Operating system]/Mouse.py's RelativeMouseScroll(), I only say it's "Relative" because it's stateless. You don't have to worry about the cursor's position or the current scroll state of whatever window you're scrolling in. You just tell the OS "Scroll this much up/down and this much left/right relative to wherever you are now." You don't care about where things are currently scrolled to.

It's kind of misleading; it wouldn't really make any sense to have a non-relative scroll (which would mean setting a given window's actual absolute scroll position). That wouldn't be useful, and would be very hard to implement.

It only makes sense to have a non-relative (i.e. absolute) mouse object because the position of the mouse is global, and there is only one mouse position to keep track of. Window scroll states are non-global, and I don't want to keep track of the scroll state of every window. I can't even think of a use case for that.

If you're talking about something else, I am misinterpreting you. But if you're talking about RelativeMouseScroll(), it could just have succinctly been named Scroll(). I was just sticking with naming convention.

[pythonian4000]

Yes, that is what I was referring to. Thanks for the clarification.

Part of my confusion is that for Xlib, scrolling is just represented as a series of "scroll up" or "scroll down" clicks, so the scroll amount is (as far as I can tell) fixed by the system (this is what I meant by "absolute" - always the same relative to the global system), whereas for OSX and Windows you can specify a particular number.

The other part is that I can't tell from your code whether the "scroll this much" number you provide (x_movement and y_movement) is an actual pixel amount or a percentage of some sort - when testing, I was only able to get values between about +1.0 to +1.5 and -1.0 to -1.5. I'm trying to find documentation on this, but I hoped that you might be able to clarify this (having already read the docs yourself, I assume).

[wyager]

Alright, glad to hear it.

For OS X, we're using by-pixel scroll amounts (kCGScrollEventUnitPixel). I think it might actually be wise to switch to point-based scroll amounts, since I don't know how this behaves on Retina devices.

For Windows, I'm not so sure. I think it might be pixel-based. The MSDN docs weren't as clear. I'm pretty sure that, in versions of windows before 7 (or maybe before vista?) the minimum scroll amount was 120, which corresponds to a single wheel click. But I think in >= 7 (or maybe >= vista), amounts less than 120 are supported, which is good for us. From what you describe, it sounds like Xlib is still using very large minimum scroll amounts (represented by a single "scroll wheel click"). I'm not sure how to work with this. I am unfortunately too ignorant about X's internal operation.

[pythonian4000]

Thanks for the additional info. I've now found the Windows and OSX docs and have a better idea of things now. I will continue helping to expand PyUserInput :)