Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2012-06-18 17:16:47
|
Hi, just a quick idea to throw into the air: I was using cntl-mouse_scroll to zoom in and out on a long data series and found myself having to adjust left and right. What some graphics programs (and ggogleearth) do in this situation is to zoom on the mouse position. This is a major improvement. Put the mouse over the point of interest and zoom in and out. The point of focus under the mouse stays in the same position and the rest scales and shifts around it. I guess this would not involve much change to the code since the zoom and the scroll is already there but in terms of usability it is a great help. best regards, Peter. |
|
From: Ethan A M. <sf...@us...> - 2012-06-18 18:44:13
|
On Monday, June 18, 2012 10:17:36 am pl...@pi... wrote: > Hi, > > just a quick idea to throw into the air: I was using cntl-mouse_scroll > to zoom in and out on a long data series and found myself having to > adjust left and right. > > What some graphics programs (and ggogleearth) do in this situation is > to zoom on the mouse position. This is a major improvement. > > Put the mouse over the point of interest and zoom in and out. The point > of focus under the mouse stays in the same position and the rest scales > and shifts around it. There was a preliminary patch submitted that would do this: https://sourceforge.net/tracker/index.php?func=detail&aid=2972660&group_id=2055&atid=302055 But it was against an earlier version of gnuplot and the submitter did not update it. If someone wants to pursue this idea, that might be a good place to start. Ethan > > I guess this would not involve much change to the code since the zoom > and the scroll is already there but in terms of usability it is a great > help. > > best regards, Peter. |
|
From: Petr M. <mi...@ph...> - 2012-06-20 05:46:11
|
> > just a quick idea to throw into the air: I was using cntl-mouse_scroll > > to zoom in and out on a long data series and found myself having to > > adjust left and right. > > > > What some graphics programs (and ggogleearth) do in this situation is > > to zoom on the mouse position. This is a major improvement. > > > > Put the mouse over the point of interest and zoom in and out. The point > > of focus under the mouse stays in the same position and the rest scales > > and shifts around it. > > There was a preliminary patch submitted that would do this: > https://sourceforge.net/tracker/index.php?func=detail&aid=2972660&group_id=2055&atid=302055 I would propose to revise mouse zooming to comply more with that used in map software (maps.google.com, mapy.cz etc.). Thus: - mouse wheel zooms around current mouse position (it could zoom around center if mouse is outside graph border) - Shift-wheel would move graph up/down (as now without Shift) - Ctrl-wheel would move graph left/right (now with Shift) I find the current behaviour counterintuitive and thus actually not using it at all :-( --- Petr |
|
From: <pl...@pi...> - 2012-06-20 07:57:33
|
On 06/20/12 07:46, Petr Mikulik wrote: >>> just a quick idea to throw into the air: I was using cntl-mouse_scroll >>> to zoom in and out on a long data series and found myself having to >>> adjust left and right. >>> >>> What some graphics programs (and ggogleearth) do in this situation is >>> to zoom on the mouse position. This is a major improvement. >>> >>> Put the mouse over the point of interest and zoom in and out. The point >>> of focus under the mouse stays in the same position and the rest scales >>> and shifts around it. >> >> There was a preliminary patch submitted that would do this: >> https://sourceforge.net/tracker/index.php?func=detail&aid=2972660&group_id=2055&atid=302055 > > I would propose to revise mouse zooming to comply more with that used in map > software (maps.google.com, mapy.cz etc.). Thus: > - mouse wheel zooms around current mouse position (it could zoom around > center if mouse is outside graph border) > - Shift-wheel would move graph up/down (as now without Shift) > - Ctrl-wheel would move graph left/right (now with Shift) > > I find the current behaviour counterintuitive and thus actually not using it > at all :-( > > --- > Petr > > Hi, I'm not sure that one is more "intuitive" that the other but I have had the same experience. It may just be what I'm used to from another interface, may be not but I find the left/right scroll to be the opposite of what I expect. It would seem to be preferable to have a de facto standard and in that sense I would suggest bowing to number of people who will be familiar the google interface. I've been using the scrolling quite a bit this week and it is a great feature. (Except for not mouse centring the zoom ;) ). I've just about retrained my brain to go the right was most of the time which probably means I'll mess up next time I use google. Falling in line with big G would seem to be the way to go. Peter. |
|
From: Mojca M. <moj...@gm...> - 2012-06-20 08:25:16
|
On Wed, Jun 20, 2012 at 7:46 AM, Petr Mikulik wrote: > > I would propose to revise mouse zooming to comply more with that used in map > software (maps.google.com, mapy.cz etc.). Thus: > - mouse wheel zooms around current mouse position (it could zoom around > center if mouse is outside graph border) > - Shift-wheel would move graph up/down (as now without Shift) > - Ctrl-wheel would move graph left/right (now with Shift) You forgot that google maps allows you to "drag and drop" to move around the map. I believe that is not an option for gnuplot (but being able to move around without holding some mouse button is crucial for me to make navigation on maps at least somewhat usable). I never use mouse wheel to scroll in google maps since it is impossible to control the amount of zoom (clicking +/- would use at least 17 different zoom steps, while I can only get 6 with the "wheel"). But maybe that's only the case on macs with high precision scrolling which is not taken into account on google maps. And I would probably get used to it quickly if implemented properly. > I find the current behaviour counterintuitive and thus actually not using it > at all :-( On modern Macs the natural way to navigate with mouse is for example the following: a) "wheel equivalent" (two fingers sliding on trackpad): move up/down (like in web browsers), but also left/right - same as now b) "pinch gesture": zoom in (usually it is uniform zooming, but one has the information about the angle and could use that information to zoom over a single axis, for example when angle is between +/- 22.5 degrees; and zooming in uniformly when angle is between 22.5 and 67.5 degrees etc.) I'm not arguing against the change (I would welcome revised code actually), I only wanted to point out that "intuitive behaviour" might not necessary be universal across different hardware & software. I definitely do miss more control in mousing events (being able to scroll in smaller steps for example, or support for zooming in with a pinch), but on the other hand the data I'm constantly dealing with nowadays typically have 10^9 points, so I need my own viewer anyway (to allow navigation without being awfully slow and running out of memory, based on assumptions I can afford to take into account in my own implementation & for my own data, not applicable to generic case in gnuplot). And it is also true that AquaTerm would not support any mousing at all. The program I'm using now allows to select a range on x axis (drag and drop just next to the axis) and a range on y axis (separately) to zoom into selected range. That is also a lot more intuitive (once you know about the option) and allows for selecting the area of interest with great precision. Mojca |
|
From: Mojca M. <moj...@gm...> - 2012-06-20 08:32:06
|
On Wed, Jun 20, 2012 at 10:25 AM, Mojca Miklavec wrote: > On Wed, Jun 20, 2012 at 7:46 AM, Petr Mikulik wrote: >> >> I would propose to revise mouse zooming to comply more with that used in map >> software (maps.google.com, mapy.cz etc.). Thus: >> - mouse wheel zooms around current mouse position (it could zoom around >> center if mouse is outside graph border) >> - Shift-wheel would move graph up/down (as now without Shift) >> - Ctrl-wheel would move graph left/right (now with Shift) > > You forgot that google maps allows you to "drag and drop" to move > around the map. I believe that is not an option for gnuplot I'm sorry. I mixed up left & right click. The right click zooms into the region, so the right click is already taken (not the left one), while left click doesn't seem to do anything. So the left click (drag and drop) could actually be used to move the graph around. > The program I'm using now allows to select a range on x axis (drag and > drop just next to the axis) and a range on y axis (separately) to zoom > into selected range. That is also a lot more intuitive (once you know > about the option) and allows for selecting the area of interest with > great precision. ... but that is already possible with the left mouse button anyway. Another nice gesture (in a different program that I'm using) is double-clicking bringing you back to original/default zoom & position. Mojca |
|
From: <pl...@pi...> - 2012-06-20 09:07:27
|
On 06/20/12 10:31, Mojca Miklavec wrote: > On Wed, Jun 20, 2012 at 10:25 AM, Mojca Miklavec wrote: >> On Wed, Jun 20, 2012 at 7:46 AM, Petr Mikulik wrote: >>> >>> I would propose to revise mouse zooming to comply more with that used in map >>> software (maps.google.com, mapy.cz etc.). Thus: >>> - mouse wheel zooms around current mouse position (it could zoom around >>> center if mouse is outside graph border) >>> - Shift-wheel would move graph up/down (as now without Shift) >>> - Ctrl-wheel would move graph left/right (now with Shift) >> >> You forgot that google maps allows you to "drag and drop" to move >> around the map. I believe that is not an option for gnuplot > > I'm sorry. I mixed up left & right click. The right click zooms into > the region, so the right click is already taken (not the left one), > while left click doesn't seem to do anything. So the left click (drag > and drop) could actually be used to move the graph around. Yes, map style dragging may be a useful extension of mouse control and I don't think any of the mouse aware terms are using that kind of button1 event. One major defect I find with the current mouse control is the need to take my eye off the screen to find shift or cntl keys. I see no reason why vert scroll should be privileged and monopolise the whole plot surface. It may be an improvement if vert and horizontal scrolling were effected by mouse scroll on the areas between the relative axis and the window edge. This would leave the graph area itself free for zoom without the need for an additional keyboard interaction. Thus both scroll actions and zoom would be freed of the need for keyboard. This would be a lot easier to use. > >> The program I'm using now allows to select a range on x axis (drag and >> drop just next to the axis) and a range on y axis (separately) to zoom >> into selected range. That is also a lot more intuitive (once you know >> about the option) and allows for selecting the area of interest with >> great precision. > > ... but that is already possible with the left mouse button anyway. > > Another nice gesture (in a different program that I'm using) is > double-clicking bringing you back to original/default zoom & position. There is already a button for that in wxt and dbl-clk event pastes current coords under mouse to paste board. This is a feature I have used quite a bit just this week. The only drawback I have with this feature is that it does not get picked up by the X11 copy buffer that can be pasted with button-3 click (mouse wheel) which is so much faster than using context menus to find paste or dropping the mouse to do cntl-v. I guess that may not be possible since the text copied is never on an Xwindow in the first place, unless there is a trick that could achieve that. Peter. |
|
From: Tait <gnu...@t4...> - 2012-06-20 12:27:56
|
> I would propose to revise mouse zooming to comply more with that used in map > software (maps.google.com, mapy.cz etc.). Thus: > - mouse wheel zooms around current mouse position (it could zoom around > center if mouse is outside graph border) > - Shift-wheel would move graph up/down (as now without Shift) > - Ctrl-wheel would move graph left/right (now with Shift) I'm used to shift+scrollwheel adjusting altitude, ctrl+scrollwheel adjusting azimuth, and meta or alt+scrollwheel being zoom. In a 2D environment, I suppose there's some logical sense to altitude being vertical scroll and azimuth being horizontal scroll, but this overlaps with the normal unmodified use of the scrollwheel for vertical and horizontal scrolling. (On mice without a horizontal scrollwheel axis, I guess just vertical scrolling?) For consistency, wouldn't we want similar bindings for the arrow keys? |
|
From: <pl...@pi...> - 2012-06-20 14:29:29
|
On 06/20/12 14:27, Tait wrote: >> I would propose to revise mouse zooming to comply more with that used in map >> >software (maps.google.com, mapy.cz etc.). Thus: >> >- mouse wheel zooms around current mouse position (it could zoom around >> > center if mouse is outside graph border) >> >- Shift-wheel would move graph up/down (as now without Shift) >> >- Ctrl-wheel would move graph left/right (now with Shift) > I'm used to ... Are you saying that you are using some commonly used software that has a sufficiently large user-base that it should be weighed into a discussion on finding some commonality ? If so , what is it? regards. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-06-20 15:27:43
|
On Wednesday, 20 June 2012, pl...@pi... wrote: > On 06/20/12 14:27, Tait wrote: > >> I would propose to revise mouse zooming to comply more with that used in map > >> >software (maps.google.com, mapy.cz etc.). Thus: > >> >- mouse wheel zooms around current mouse position (it could zoom around > >> > center if mouse is outside graph border) > >> >- Shift-wheel would move graph up/down (as now without Shift) > >> >- Ctrl-wheel would move graph left/right (now with Shift) > > > I'm used to [...] > > the normal unmodified use of the scrollwheel for vertical and > > horizontal scrolling > > Are you saying that you are using some commonly used software that has a > sufficiently large user-base that it should be weighed into a > discussion on finding some commonality ? > > If so , what is it? Every web browser? FWIW, I think that mouse "button events" 4+5 are in the X11 protocol as up/down scroll, while button events 6+7 are left/right scroll. Most mouse wheels send events 4+5, although sometimes you can reconfigure this in the mouse driver (or xconfig). At Mojca's suggestion, we added 6+7 as left/right scroll recently because it seems that touch-screen devices use this same set of event codes to indicate up/down left/right dragging. I don't so much care what convention gnuplot uses for a "real" mouse wheel, but I think it is important that it is interpreted as left/right up/down scrolling on a touch screen. Ethan |
|
From: Tait <gnu...@t4...> - 2012-06-21 01:58:46
|
> Are you saying that you are using some commonly used software that has a > sufficiently large user-base that it should be weighed into a > discussion on finding some commonality ? > > If so , what is it? > > regards. I didn't have any one particular software in mind, just a common theme that seems to apply to programs I've used: mapping (e.g. Google Earth, NGTE), VRML viewers (e.g. web browsers), document viewers for PDF (e.g. Acrobat), image editing (e.g. Photoshop), and solid design (CAD programs like AutoCad or SolidWorks). A common exception seems to be using ctrl+wheel for radial/zoom control (like Windows, Mathematica, web browsers). |
|
From: <pl...@pi...> - 2012-06-21 06:15:03
|
On 06/21/12 03:58, Tait wrote: >> Are you saying that you are using some commonly used software that has a >> sufficiently large user-base that it should be weighed into a >> discussion on finding some commonality ? >> >> If so , what is it? >> >> regards. > > I didn't have any one particular software in mind, just a common theme > that seems to apply to programs I've used: mapping (e.g. Google Earth, > NGTE), VRML viewers (e.g. web browsers), document viewers for PDF > (e.g. Acrobat), image editing (e.g. Photoshop), and solid design (CAD > programs like AutoCad or SolidWorks). > > A common exception seems to be using ctrl+wheel for radial/zoom control > (like Windows, Mathematica, web browsers). > > I tend only to zoom in/out one level or so in web browser so I use keys , but you are correct , ctrl+wheel is used for zoom in firefox at least. However, GoogleEarth zooms on mouse wheel only. As do their embedded versions on googlemaps. I used kicad CAD software which zooms on the mouse position using mouse wheel only. This is a fast and efficient way of getting around. Equally, Gimp is configurable and I have set up mouse+wheel on the image for similar behaviour, this leaves mouse events over the scrollbars for conventional scrolling. Clearly 4,5,6,7 are scroll events , the question is how does any particular prograrm interpret them. Document viewers like browsers and PDF work on larger documents that typically do not fit on the screen. It is the whole document that is being scrolled/zoomed. The viewer has scrollbars for both directions that enable vert/horiz scrolling without recourse to keyboard modifiers. How happy would anyone be if they had to press the shift key to h-scroll a web page. Indeed, I think it's fair to say the graphs more often need scrolling horizontally so the inconvenience is perhaps more comparable to having to use a modifier to v-scroll a web page. In gnuplot the axes always fit into the window and there are no scrollbars. Even the scroll feature is fairly new (thanks Ethan + Phil Jarret). I see three possible ways this level of interaction could be made a lot more efficient. 1. a mouse only zoom control 2. an active region that can act like a scrollbar for each direction (ie mouse only scroll) 3. drag-drop within axes bounds. If there is agreement on the desirability of any of those functions then we could look at how they can be achieved without compromising tactile devices, for example. Peter. |
|
From: Petr M. <mi...@ph...> - 2012-06-23 21:24:03
|
I have revised the mouse wheel zooming, see patch: https://sourceforge.net/tracker/?func=detail&aid=3537423&group_id=2055&atid=302055 Tested using a normal USB mouse. Hotkeys are useful when using touchpad. Hope you like it. --- Petr |
|
From: Mojca M. <moj...@gm...> - 2012-06-25 08:21:43
|
On Sat, Jun 23, 2012 at 11:23 PM, Petr Mikulik wrote: > I have revised the mouse wheel zooming, see patch: > https://sourceforge.net/tracker/?func=detail&aid=3537423&group_id=2055&atid=302055 Thank you. However (the following comments are all unrelated to your specific change), if revising the mouse, I would be very very very grateful if functions would be modified in such a way that it would be possible to specify the amount of zoom/scroll, not only large discrete steps. Currently a single scroll event moves the graph for approximately 15-40 pixels, while macs allow precise scrolling with pixel precision. On Mac mouse scrolling events return: - scrolling direction (up/down or left/right) - the number of pixels to scroll and typically one gets several events one after another. It is practically impossible, or at least very inconvenient to 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 the screen. I volunteer to fix this behaviour in Qt & wxt, but there is no suitable function to call directly. At the moment I can only "forward wheel scrolling event", discarding the amount of scrolling (otherwise it would behave even worse than it does now), but that makes unproportional movement, depending on the speed of movement, not the amount of movement. So it would be very helpful to have not just zoom_around_mouse('+'); but rather something like zoom_around_mouse(1.134); Also, as soon as one uses a scrolling event, the default behaviour is the following (one example): if (((b == 5) && (modifier_mask & Mod_Shift)) || (b == 7)) { /* scroll right */ xmin = rescale(FIRST_X_AXIS, .9, .1); ymin = rescale(FIRST_Y_AXIS, 1., 0.); x2min = rescale(SECOND_X_AXIS, .9, .1); y2min = rescale(SECOND_Y_AXIS, 1., 0.); xmax = rescale(FIRST_X_AXIS, -.1, 1.1); ymax = rescale(FIRST_Y_AXIS, 0., 1.); x2max = rescale(SECOND_X_AXIS, -.1, 1.1); y2max = rescale(SECOND_Y_AXIS, 0., 1.); do_zoom(xmin, ymin, x2min, y2min, xmax, ymax, x2max, y2max); with hardcoded 10% movement. It would be a lot more useful to have a finer control of the amount of zoom & movement than just discrete hardcoded steps. I wanted to change the code, but I'm not sure where to start. From Qt I can only forward scrolling event or do some other dirty trickery without knowing much about gnuplot internals. And related to your change: on Mac it is natural to use scrolling for actually scrolling, since there are other events on trackpad which allow zooming in (they work the same as maps on smart phones, using two fingers and sliding them closer together or further apart). Redefining the meaning of scrolling means a slightly unnatural experience for mac users, but for the sake of all other more widespread OS-es and hardware and for the sake of consistency of gnuplot across platforms, it should be acceptable to use key combinations that make sense elsewhere. However ... if you redefine the meaning of scrolling event, then please provide drag-and-drop to move around the graph. Thank you, Mojca |
|
From: <pl...@pi...> - 2012-06-25 13:34:08
|
On 06/25/12 10:21, Mojca Miklavec wrote: > However ... if you redefine the meaning of scrolling event, then > please provide drag-and-drop to move around the graph. > > Thank you, > Mojca Yes, I think this much could be done without confusion or conflicts and would get a least one operation free of the keyboards, at the same time as providing an interface familiar from pdf viewers and map display software. thanks again for giving this some attention. Peter. |
|
From: <pl...@pi...> - 2012-06-25 13:34:08
|
On 06/25/12 10:21, Mojca Miklavec wrote: > And related to your change: on Mac it is natural to use scrolling for > actually scrolling, since there are other events on trackpad which > allow zooming in (they work the same as maps on smart phones, using > two fingers and sliding them closer together or further apart). Does this work on gnuplot ? Do you know what event stream this two finger gesture sends to the program with the input focus? What point does it scroll on? Finger one; mid pt between fingers; screen centre ? thx |
|
From: Mojca M. <moj...@gm...> - 2012-06-25 16:26:28
|
On Mon, Jun 25, 2012 at 3:25 PM, <pl...@pi...> wrote:
> On 06/25/12 10:21, Mojca Miklavec wrote:
>> And related to your change: on Mac it is natural to use scrolling for
>> actually scrolling, since there are other events on trackpad which
>> allow zooming in (they work the same as maps on smart phones, using
>> two fingers and sliding them closer together or further apart).
>
> Does this work on gnuplot ?
Not yet. If I haven't lost it yet, I have a working code for Qt which
intercepts & interprets events (by printing out "this is zoom for W%
around point (X,Y), direction Z"), but I would need (for example your)
code to actually resize the plot/redraw contents. That is: I would
need a function in gnuplot which I could call to do the resizing.
> Do you know what event stream this two finger gesture sends to the
> program with the input focus?
It depends a bit. Here is one example program written in Qt:
http://qt-project.org/doc/qt-4.8/touch-pinchzoom.html
And here is some Cocoa documentation:
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/EventOverview/HandlingTouchEvents/HandlingTouchEvents.html
I don't believe that it would be possible to implement this in X11 (I
might be wrong), in Qt it would be easiest since Qt has up-to-date
support for all Mac OS X sugars, while in wxt it might be only
conditionally doable. Aqua needs mouse support in the first place.
> What point does it scroll on? Finger one; mid pt between fingers; screen
> centre ?
Are we talking about zooming in or moving contents around. If it is
about zooming in, Cocoa returns the middle point between fingers as
the center point, at least I think so. I never did any extensive
experiments, but I could try to play with your code and Qt a bit.
Mojca
PS: There is one minor "problem" though for which I don't think that
gnuplot could be tweaked easily. A smart application would move or
scale current picture during mouse movement without recalculating and
redrawing everything, and only redraw the final image once the mouse
movement is complete. I'm a bit afraid of big speed penalties if
smooth mouse movements are implemented without some intermediate
optimizations.
|
|
From: Mojca M. <moj...@gm...> - 2012-06-25 16:28:42
|
On Mon, Jun 25, 2012 at 6:26 PM, Mojca Miklavec wrote: > I have a working code for Qt which > intercepts & interprets events (by printing out "this is zoom for W% > around point (X,Y), direction Z"), but I would need (for example your) > code to actually resize the plot/redraw contents. Sorry, I meant "for example Peter's". Mojca |
|
From: <pl...@pi...> - 2012-06-25 17:06:42
|
On 06/25/12 18:26, Mojca Miklavec wrote: > (for example your) Please note Petr != Peter. It's not a typo. ;) |
|
From: Petr M. <mi...@ph...> - 2012-06-25 21:57:32
|
> On Sat, Jun 23, 2012 at 11:23 PM, Petr Mikulik wrote: > > I have revised the mouse wheel zooming, see patch: > > https://sourceforge.net/tracker/?func=detail&aid=3537423&group_id=2055&atid=302055 > > However (the following comments are all unrelated to your specific > change), if revising the mouse, I would be very very very grateful if > functions would be modified in such a way that it would be possible to > specify the amount of zoom/scroll, not only large discrete steps. I have tested the changes with an USB mouse attached to my notebook. But it seems you write only about touchpads? (I don't like touchpads. It's a hardware thing that goes worse and worse :-) That one I have in my Asus notebook is horrible - it is large and flat (without edges) but not centered with respect to F and J keys on the keyboard so that typing by 10 fingers makes strange things. Hm, yes, sometimes I use it ... but I find hitting Arrow or Pg keys much faster for scrolling.) > 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? > 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? > And related to your change: on Mac it is natural to use scrolling for > actually scrolling, since there are other events on trackpad which > allow zooming in (they work the same as maps on smart phones, using > two fingers and sliding them closer together or further apart). > Redefining the meaning of scrolling means a slightly unnatural > experience for mac users, but for the sake of all other more > widespread OS-es and hardware and for the sake of consistency of > gnuplot across platforms, it should be acceptable to use key > combinations that make sense elsewhere. > > However ... if you redefine the meaning of scrolling event, then > please provide drag-and-drop to move around the graph. So it seems you want different mapping for events generated by touchpads and trackpoints than events for mouses, 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. Is it possible to know the input device sending the event? --- PM |
|
From: Mojca M. <moj...@gm...> - 2012-06-25 23:55:35
|
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
|
|
From: Petr M. <mi...@ph...> - 2012-07-10 15:26:45
|
> >> So it would be very helpful to have not just
> >> zoom_around_mouse('+');
> >> but rather something like
> >> zoom_around_mouse(1.134);
I have added this to the patch.
Now you can use a shift factor for scrolling (10% shift is the default) and
speed for zooming (cca 0.92 and 1.14 being the default, otherwise
pow(0.92 or 1.14, speed).
Maybe the shift can also be a power instead of that value.
Please try it. Think it over how to pass and evaluate those delta's of fine
values of mousepad or touchscreen.
> if you redefine the meaning of scrolling event, then please provide
> drag-and-drop to move around the graph.
You mean click-and-drag, not drag&drop (=dropping objects into the canvas)?
That would need to go inside button press and release functions in mouse.c.
If MB3 is clicked (and not released), then allow dragging, otherwise show
current zoom box.
---
Petr
|
