Re: High-resolution scroll events

[Shaun McCance <shaunm gnome org>]

On Wed, 2010-11-17 at 16:53 +0100, Max Schwarz wrote:
> Am Mittwoch, 17. November 2010, um 16:40:16 schrieben Sie:
> > On Wed, Nov 17, 2010 at 10:25 AM, Max Schwarz <Max x-quadraht de> wrote:
> > > The problem is not with large deltas (which are thrown away in the
> > > current OSX version, if I understand the patch correctly), but with
> > > small deltas, which get emitted from Xorg with a pretty high frequency.
> > 
> > my initial response to this was sent by completely forgetting what i
> > had done with the original version of the patch. so no, its not true
> > that anything is thrown away. the patch actually adds a new field to
> > scroll events, so that they can have the same semantics as the events
> > on win and quartz.
> 
> That's correct, but the un-patched port throws away large deltas (there's a 
> "break;" in there somewhere), and you got around it by storing the deltas in 
> the events.
> 
> What do you do with small -0.0001/+0.0001 deltas from Xorg? That's the 
> question. If you forward it in GdkEventScroll (and optionally encode that in 
> the proposed delta field), old applications end up getting many GdkEventScroll 
> events, which they interpret as regular scroll events.
> Result: you scroll a mile when you just move your finger a little bit :-(
> 
> That's the problem I see. Or is the only receiver of the events GTK itself 
> (GtkRange&co)? Then it would be possible to patch it all at once...

Most application code probably doesn't use GdkEventScroll
directly. It's handled inside GTK+ for things like scrolled
windows. But some applications and some libraries might use
GdkEventScroll for something clever. I know vte uses it to
let your scroll wheel work in programs like less.

If we break API on this, I think it would be best to do it
in a way that the compiler catches it. Just adding a field
to GdkEventScroll will trip up a lot of developers.

-- 
Shaun McCance
http://syllogist.net/