Re: mouse zoom centred on mouse position.

[<pl...@pi...>]

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.