Smooth scrolling

[Éric Piel]

Op 07-04-10 20:30, Max Schwarz schreef:
> Am Mittwoch 07 April 2010 16:13:09 schrieben Sie:
>> First, you could have one factor which governs how many valuator scroll
>> steps are needed to trigger one button scroll event, as discussed above.
>> This would need to be enforced by the driver. If a mouse is clicky, it
>> may be 1 or the driver would multiply it to match some target value like
>> 100. The main question is whether apps need to or shouldn't know that
>> factor. I think that's what Eric meant.
> Eric wanted to scale the reported valuator value so that it is in relative 
> units to the old clicks, if I understood correctly.
What I wanted to say is that there is a need for an _official_ value of
how much is a click in this new (almost) continue space. Otherwise we
might end up with drivers saying that a click is 20u, other drivers
converting it to 33u, and others to 100u. Similarly, without a specific
value, an app could move three lines for 10 units, while another would
would move only 2.3 lines. And it's especially important for when those
clicks are currently mapped to actions that cannot be cut in small
pieces (like moving to the next picture in a slideshow, going back and
forward in the webpage history...).

Failure to have a single value to map one click to one action would lead
to lots of small very frustrating regressions. That's why I was
suggesting 100u (or whatever other number which fits) to be set in
stone. That said, the usage of the resolution field to carry the
"units/scrollclick" would probably work as well. It's like an official
value dependant on the driver. It just requires to make sure that the
normal meaning of resolution will never be useful in this context (and a
priori, I cannot think of any use), and that the core pointer does the
appropriate conversion when merging several devices.

Eric