Smooth scrolling
Simon Thum
simon.thum at gmx.de
Wed Apr 7 07:13:09 PDT 2010
Am 07.04.2010 13:55, schrieb Max Schwarz:
> On Wed, 2010-04-07 at 12:58:11, Simon Thum wrote:
>> I'm unsure I get it. I assumed you were breaking up the 1:1 relation
>> between scroll button presses and your scroll valuator, such that the
>> valuator may work with much higher precision while button-scroll remains
>> working for apps unaware of the scroll valuator(s). Is that intended?
>
> Yes, that's correct. But the relationship between the hardware axis and scroll
> valuator is defined by the driver, that's all I wanted to say.
I guess strictly speaking you mean per device (initially defined by the
driver). Sounds fine.
> A scroll valuator unit as proposed by Eric (unit relative to old scroll wheel
> presses) is a good idea in my opinion. In that way the value is independant of
> screen resolution and font size, and toolkits can then decide how many pixels
> to scroll depending on those values.
I think there is some confusion around this. There's two things:
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.
Additionally, one might want a device-specific value which is mainly up
to interpretation by apps aware of it, to give some guidance on what is
a sensible response to scroll events. Possibly, this would be separately
specified for scroll valuators and scroll button events, but the
distance in that case would end up being much the same as the
driver-enforced relation.
Personally, I like to have both.
>
> Max
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
>
More information about the xorg-devel
mailing list