[PATCH weston 4/8] shell: Update bindings to conform to pointer axis protocol

[Jonas Ådahl]

On Thu, Oct 4, 2012 at 1:33 PM, Daniel Stone <daniel at fooishbar.org> wrote:
> Hi,
>
> On 4 October 2012 17:06, Jonas Ådahl <jadahl at gmail.com> wrote:
>> On Thu, Oct 4, 2012 at 12:47 AM, Daniel Stone <daniel at fooishbar.org> wrote:
>>> I agree it makes perfect sense, but note that axis events are already
>>> fixed-point, so you already get fairly fluid motion (motion in units
>>> of 1/256th of a wheel 'chunk', i.e. already subpixel).  The only
>>> advantage of making it pixel-based is that clients no longer have to
>>> do the multiplication.  But some applications don't want to smoothly
>>> scroll by pixels, and instead just want to, e.g, flip a page, every
>>> time the scroll motion passes a certain threshold.
>>
>> The major difference between the (even smooth) step-based approach is
>> that it makes it possible to have scroll events that "feel" the same
>> as motion events (again, talking about touchpads here). By scaling
>> down the motion vector it would make it more or less impossible
>> without communicating factors to get axis events as if they were
>> motion events.
>
> As I said, you don't want scrolling to have the same acceleration as
> pointer motion anyway - at least IMHO.

Acceleration or not, that's (in this case) a detail of the touchpad
implementation and unrelated to the axis protocol itself.

>
>> I think step based scrolling can be useful as well, but I think its
>> use cases are different from scrolling view ports. For example games
>> probably want to make use of scroll steps to change some state, but
>> wont do so with a the fractional steps. I'd say that having another
>> type of axis (say "horizontal/vertical step") for those types would
>> make more sense.
>
> I still think the current approach makes the most sense though, as it
> makes both possible.  Though for touchpad scrolling where you want
> chunks, you probably want to know when the scroll motion started and
> when it stopped, rather than how many chunks it progressed through.

For touchpad scrolling, chunks is what you want to avoid. You want the
scrolling to be as smooth as moving the pointer, and you want it to
behave similar, IMHO. If scrolling is measured in arbitrary steps, it
is impossible for the client to behave as one would expect in the
mentioned case since the toolkit is unaware of what factor touchpad
driver used to generate the steps.

Jonas