The paradox of scrolling direction (and further problems with scrolling delta)

[Mojca M. <moj...@gm...>]

Hi,

this is a somewhat longer email (it's probably also very difficult to
both explain and understand what is going on without a video - I can
provide one if needed), trying to address the following issues:
a) problems with scrolling directions
b) scrolling delta


a) Scrolling direction, related to:
- 2013-03-17 mouse wheel and +/- keys zoom centered on current mouse position
- 2012-01-15 Pass horizontal scroll events through to gnuplot core as
mouse event 6/7

Short version: the patch on 2013-03-17 breaks horizontal scrolling
direction (at least on Mac; on Windows it probably doesn't work
anyway; on my Linux everything seems to be semi-broken).

The long version:
I contributed the first trivial patch when testing more or less
exclusively on Mac. I'm using trackpad
(http://www.apple.com/magictrackpad/) on OS X 10.7 (Lion) which was
the first OS X version that "reversed" the scrolling direction to make
it consistent with iPhones, iPads and other touch devices. That is: if
two fingers slide *up* (away), the page also moves up, but the reading
focus moves *down* the page (equivalent of scrolling down on a normal
mouse) and vice versa. The setting is called "Scroll direction:
natural (Content tracks finger movement)" and can be optionally
switched off. (It was annoying the first few hours of using it, but
it's indeed more natural and it gets more annoying to switch back.) In
the same way one needs to slide fingers from right to left in order to
be able to read a long line of text (the usual left-to-right
direction): the text moves left, but now the eyes finally get to see
the right part of the text.

When using Qt on Mac with "natural scroll direction" turned on
(default since 10.7), sliding with fingers from bottom to top results
in negative event->delta() and  the following code
  // 4 = scroll up, 5 = scroll down
  m_eventHandler->postTermEvent(GE_buttonpress,
    int(event->scenePos().x()), int(event->scenePos().y()),
    event->delta() > 0 ? 4 : 5, 0, 0);
triggers "mouse button 5". The graph moves up, the y axis turns more
negative and all is OK.

When sliding from right to left event->delta() is negative and the
following code
  // 6 = scroll left, 7 = scroll right
  m_eventHandler->postTermEvent(GE_buttonpress,
    int(event->scenePos().x()), int(event->scenePos().y()),
    event->delta() > 0 ? 6 : 7, 0, 0);
triggers "mouse button 7" (scroll right). The problem is that this
worked perfectly fine until 2013-03-17. Now it is sliding in the
opposite direction as it is supposed to.

Note that if I switch the "natural scroll direction" off, the same
actions trigger mouse buttons 4 and 6 respectively.

So scrolling works properly in the released version, but in trunk
version the horizontal scrolling is reversed, at least on Mac. (I
would love to test how this works on *the same* trackpad on Linux, but
I'm reluctant to go through the hell of installing linux on a mac via
dual/tri boot and all my past attempts to boot from USB key on a Mac
machine failed.)

Horizontal scrolling in X11 on Mac is also wrong after the latest
change and worked properly earlier.

-----     -----     -----

Last week my parents bought a new notebook (the cheapest Lenovo) with
a magnificent Synaptic touchpad (videos available on
http://www.synaptics.com/solutions/technology/touchpad). I installed
Kubuntu 13.04 and (I think) libqt4-dev to compile gnuplot. (I can try
with Qt5, but I need to figure out which libraries exactly are needed
first, and I doubt that it would change anything at all.)

The very first thing I changed in settings was to reverse scrolling
direction of the mouse (see
http://www.maketecheasier.com/reverse-mouse-scrolling-direction-in-ubuntu/2011/09/16),
so that the touchpad now behaves exactly as it does on a Mac. (On
Windows I first had to upgrade the touchpad drivers to the latest
version to be able to do that and to enable horizontal scrolling.)

The funny thing: with scrolling direction reversed (non-default
behaviour) the gnuplot code from trunk works properly on linux for
horizontal *and* vertical scrolling. But if I switch back to default
settings, vertical scrolling direction changes, but horizontal
scrolling direction stays the same and thus becomes inconsistent with
vertical behaviour.

I can imagine that these settings on linux might make sense when using
a mouse with a scrolling wheel, one button on the left and one button
on the right. One might want to change the behaviour of the scrolling
wheel, but left & right buttons should stay left & right.

However, with an advanced touchpad it's totally annoying and KDE as
released with the latest Kubuntu doesn't have any setting to reverse
horizontal scrolling direction, only the vertical one (the vertical
direction can be changed under "mouse" and the horizontal one can be
switched on under "touchpad" - maybe this also explains a few
inconsistencies). Another Qt-base program, TeXworks, scrolls in
exactly the opposite horizontal direction as gnuplot does (so it's
consistent with vertical scrolling under default settings and
inconsistent when vertical scrolling direction is reversed).

I also tried to test on Windows, but it would take me too much time to
figure out how to compile gnuplot with sufficient libraries, so I only
tested the binary from sourceforge with wxt (qt is missing), but
horizontal scrolling didn't work there at all. The horizontal scroll
bar showed up, but the graph didn't move. I suspect that wxt on
windows is lacking support for horizontal scrolling, but honestly I
don't really know. (Just for comparison: under "natural scrolling"
setting in Opera horizontal scrolling works fine, in LibreOffice Calc
it's reveresed, and most programs aren't aware of horizontal scrolling
at all. Out of all PDF viewers that I tried only one had support for
pinch/zoom events and that one goes to next/previous page when
horizontal scrolling is used.)

It seems to me that:
i) The current horizontal scrolling direction in gnuplot is wrong
(that is: I suspect that do_zoom_scroll_left() &
do_zoom_scroll_right() should be switched).
ii) The behaviour of horizontal scrolling must be wrong somewhere in
Linux: either in trackpad drivers, somewhere in KDE or ... (I'm not
exactly sure how linux libraries work together).

The cure for (i) could be the following:

--- src/mouse.c
+++ src/mouse.c
@@ -1505,7 +1505,7 @@ zoom_rescale_xyx2y2(double a0,double a1,double
a2,double a3,double a4,double a5,
 static void
 do_zoom_scroll_left()
 {
-    zoom_rescale_xyx2y2(1.1,-0.1, 1,0, 1.1,-0.1, 1,0,  0.1,0.9, 0,1,
0.1,0.9, 0,1,
+    zoom_rescale_xyx2y2(0.9,0.1, 1,0, 0.9,0.1, 1,0,  -0.1,1.1, 0,1,
-0.1,1.1, 0,1,
        "scroll left.\n");
 }

@@ -1513,7 +1513,7 @@ do_zoom_scroll_left()
 static void
 do_zoom_scroll_right()
 {
-    zoom_rescale_xyx2y2(0.9,0.1, 1,0, 0.9,0.1, 1,0,  -0.1,1.1, 0,1,
-0.1,1.1, 0,1,
+    zoom_rescale_xyx2y2(1.1,-0.1, 1,0, 1.1,-0.1, 1,0,  0.1,0.9, 0,1,
0.1,0.9, 0,1,
        "scroll right");
 }

(NB: the same function is also used in builtin_rotate_left and I'm not
sure what that one does; it's very likely that code would have to be
changed in some other places as well, depending on how different key
combinations work and how they are documented, like Shift+scroll etc.)

or the following:

--- src/mouse.c
+++ src/mouse.c
@@ -1730,7 +1730,7 @@ event_buttonpress(struct gp_event_t *ge)

        /* Horizontal stroke (button 6) or Shift+wheel up */
        else if (b == 6 || (modifier_mask & Mod_Shift))
-           do_zoom_scroll_right();
+           do_zoom_scroll_left();

        /* Wheel up (no modifier keys) */
        else
@@ -1750,7 +1750,7 @@ event_buttonpress(struct gp_event_t *ge)

        /* Horizontal stroke (button 7) or Shift+wheel down */
        else if (b == 7 || (modifier_mask & Mod_Shift))
-           do_zoom_scroll_left();
+           do_zoom_scroll_right();

        /* Wheel down (no modifier keys) */
        else

or maybe something else, depending on what people perceive that
"scroll left/right" should mean (compared to "scroll up/down": when
you scroll down, the image actually goes up, not down).

It is true that this would semi-work on some linux boxes, but the
problem on those seems to be elsewhere.


b) Scrolling delta: Qt under Mac uses scrolling delta between 2 and 6
on average (but it can be much bigger depending on the speed of
fingers), while under KDE it is always 120 (or possibly multiples of
it: 240, ... 600). I tried to change settings for speed, but all that
does is possibly change when one event is triggered.

On Mac this is a huge problem for two reasons:

i) Typically a single slide/scroll creates approximately 10 small
events (but it can generate hundreds). It is almost impossible to
scroll for a small amount. One should really take that delta into
account. Petr added partial support to address that problem (email on
2012-07-10, also a patch on sourceforge), but one still needs to
change the way mouse events are handled in the gnuplot core. Currently
a scrolling event with delta 2 or delta 120 results in the same action
and this needs to be addressed somehow.

ii) Even if (i) is addressed, it will still be awfully slow on Macs to
redraw everything ten times for a single slide/scroll. On x11 on Mac
this is not a problem, but Qt really needs some special handling.



Even if the problem (b) is too complicated to solve *right now*: would
it be possible/acceptable to at least reverse direction of horizontal
scrolling (a)? It would be best if Petr would suggest the best
solution since he's the author of the major patch that has been
applied three months ago.

Thank you,
    Mojca