Re: mouse zoom centred on mouse position.

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

On Mon, Jun 25, 2012 at 11:57 PM, Petr Mikulik wrote:
>
> I have tested the changes with an USB mouse attached to my notebook.
> But it seems you write only about touchpads?

Apple's trackpad + latest mouses by Apple (I never used one) +
touchscreens (but as long as there is no nice port of gnuplot to a
phone or tablet, those can be ignored).

> (I don't like touchpads. It's a hardware thing that goes worse and worse :-)

In particular, I wasn't talking about any trackpad, but about Apple's
trackpad in particular, and even then I never tested to what extent Qt
applications under Windows/Linux also support those gestures.

>> generate one single scrolling event for one pixel. Usually one gets
>> 2-5 steps with very very tiny movement. Last time when I tested, a
>> single swipe from left to right moved me from default (-10,10) to
>> somewhere around 2000. With a single movement!!! In a native mac
>> application that would correspond to a movement across the width of
>
> Does it mean that touchpad and mouse have very different sensitivity on Mac?

newer trackpads & newer mouses: high sensitivity (for scrolling;
allows zooming in)
older mouses: lower sensitivity (= same as a normal pc mouse), no
support for zooming in
older trackpads: I forgot about sensitivity, but probably no support
for zooming in either

>> So it would be very helpful to have not just
>>     zoom_around_mouse('+');
>> but rather something like
>>     zoom_around_mouse(1.134);
>
> Or a global variable mouse_sensitivity?

What I want to say is that the lowest level function that does zoom in
should have an argument of type "double", not just a "boolean"
(whether to zoom in or out). And then the higher level function could
call it with some default parameter which could be read from a global
variable or from user setting. But the main idea would be not to have
just:
    void zoom(bool in_or_out)
    void shift_x()
    void shift_y()
but rather something like:
    void zoom(double ratio);
    void shift(int pixels_x, int pixels_y);
    void zoom_in() { zoom(1.1); }
    void zoom_out() { zoom(0.9); }
    void shift_right() { shift(0.1*term->size_x,0); }
    void shift_left() { shift(-0.1*term->size_x,0); }
    void shift_up() { shift(0, 0.1*term->size_x); }
    void shift_down() { shift(0, -0.1*term->size_x); }

> So it seems you want different mapping for events generated by touchpads and
> trackpoints than events for mouses,

I'm not sure about that.

With current behaviour I would only have to add "zoom in" events and I
would be done. But if behaviour changes ... I'm not exactly sure about
what would be the best approach.

> because, by chance, the mouse wheel
> up/down events useful for zooming correspond to y-sliding touchpad while
> x-sliding and double-finger gestures on touchpad have no mouse equivalents.

That is true. (Some mouses might have x-sliding though.)

> Is it possible to know the input device sending the event?

Zoom in (pinch) can only be sent by a modern trackpad/mouse.

I'm not sure if it is possible to know whether scrolling is done by an
old mouse or by trackpad, but you can safely assume that the majority
of mac users is using a modern mouse/trackpad. Cocoa is aware of
whether mouse/trackpad has high precision scrolling enabled or not,
but I doubt that one can check that on windows, x11, ... where
trackpad "scrolling"/sliding probably sends exactly the same events as
mouse wheel scrolling. It would be horribly confusing for a Mac user
if X11 and wxt/qt would behave considerably different on the same
machine & with the same binary. That is: scrolling/sliding should
probably not mean "zoom in" in x11 and "move up" in qt in the same
program.


Under wxt (see http://docs.wxwidgets.org/trunk/classwx_mouse_event.html)
there is

    int GetWheelDelta () const
 	Get wheel delta, normally 120.

which is most probably different (smaller) on a modern mouse/trackpad
than on traditional mouses.

In Qt there is

    int QWheelEvent::delta () const

Returns the distance that the wheel is rotated, in eighths of a
degree. A positive value indicates that the wheel was rotated forwards
away from the user; a negative value indicates that the wheel was
rotated backwards toward the user.

Most mouse types work in steps of 15 degrees, in which case the delta
value is a multiple of 120; i.e., 120 units * 1/8 = 15 degrees.

However, some mice have finer-resolution wheels and send delta values
that are less than 120 units (less than 15 degrees). To support this
possibility, you can either cumulatively add the delta values from
events until the value of 120 is reached, then scroll the widget, or
you can partially scroll the widget in response to each wheel event.


Mojca