OpenLayers OpenLayers

Ticket #341 (closed feature: fixed)

Opened 2 years ago

Last modified 1 year ago

Mouse wheel scroll should zoom in/out over mouse pointer location

Reported by: sderle Assigned to: sderle
Priority: minor Milestone: 2.4 Release
Component: Control.MouseDefaults Version:
Keywords: Cc:
State:

Description (Last modified by sderle)

at present it simply zooms in/out over the map center. this is actually kind of counterintuitive.

Attachments

MouseDefaults.js.diff (2.0 kB) - added by fredj on 11/17/06 08:35:18.
MouseDefaults.js patch (mouse wheel)
MouseDefaults_2.js.diff (3.4 kB) - added by openlayers on 12/21/06 07:45:37.
cleaner version: change Map getResolution to accept an optional zoom level. fredj
341.patch (2.9 kB) - added by sderle on 03/23/07 13:11:03.
see http://trac.openlayers.org/ticket/341#comment:18 for description

Change History

10/10/06 13:26:02 changed by sderle

  • description changed.

10/25/06 06:28:14 changed by euzuro

  • owner changed.
  • component changed from general to Control.MouseDefaults.

11/17/06 08:35:18 changed by fredj

  • attachment MouseDefaults.js.diff added.

MouseDefaults.js patch (mouse wheel)

11/17/06 10:11:17 changed by fredj

MouseDefaults.js.diff patch should fix it.

Note that the mouse position is stored in defaultMouseMove and used in onWheelEvent because mozilla has a bug with clientX and clientY and the DOMMouseScroll Event. See https://bugzilla.mozilla.org/show_bug.cgi?id=352179

Tested with FF 1.5 and IE 6.0

11/17/06 10:17:38 changed by crschmidt

  • keywords set to review icla.

Needs review, but is also pending on an ICLA. Mail sent to dev list looking for fredj.

11/17/06 15:27:56 changed by sderle

  • keywords changed from review icla to approved icla.

I have reviewed this patch and I approve it for application to trunk, pending receipt of the submitter's ICLA.

11/21/06 04:33:31 changed by euzuro

  • status changed from new to closed.
  • resolution set to fixed.

patch applied to trunk with r1945. thanks frédéric!

12/08/06 10:42:22 changed by euzuro

  • status changed from closed to reopened.
  • resolution deleted.

12/08/06 10:46:27 changed by euzuro

I'm reopening this ticket because I believe that it can be made better. This is based on comments from users@ list by John Cole:

I saw that mouse wheel zooming recently changed to zoom to the point under
the mouse.  Unfortunately, there is a problem with the current
implementation.  It would be nice to have an option to use the simpler zoom
in/out on center also.

When you allow multiple zooms on the mouse wheel, you will end up somewhere
other than where your mouse is.  The reason for this is the new center point
is calculated with the new zoom level boundaries, instead of the original.
The mouse zoom should not update the extent until the map has reloaded.

For an example, using the SVN openlayers, bring up a map with the
mousedefault control, put the mouse over a feature near the edge of the map
and give the mouse wheel a good turn up (zoom in), the new zoom point will
have drifted way off, and your feature will not appear on the map.  If you
scroll only on click, it works perfectly.

Contrary to previous belief, gmaps does not zoom in on the mouseposition point, but rather zooms in/out in a manner such that the mouseposition point's geoequivalent remains the same at the new zoom level. Which is to say that if you're looking at a map of europe and you hover over moscow way on the far right and then you mousewheel in or out... at the new zoom level, moscow will still be exactly where it was (far right) in the previous level.

Obviously, this is not simple as it requires more than just a simple zoomIn() or zoomOut() -- it will require panning as well, or a calculation of the new centerpoint.

At any rate, I think J.C.'s comments prove this something that we should look into.

12/08/06 10:46:42 changed by euzuro

  • keywords deleted.
  • milestone deleted.

12/08/06 10:46:51 changed by euzuro

  • version set to 2.2.

12/08/06 10:48:28 changed by euzuro

furhter mousewheel-related comment from John Cole's email (see above) that I believe is worth looking into:

Finally,  when mouse wheel zooming, if you zoom in or out and back to your
original level, it should be treated as a pan or simply canceled, so the
layers don't (necessarily) have to be refreshed.

12/08/06 10:52:45 changed by euzuro

  • version deleted.

12/12/06 03:26:32 changed by openlayers

MouseDefaults_2.js.diff should fix the mouse position problem reported by John Cole.

I needed to get the resolution for the next/previous zoom level and maybe

this.map.baseLayer.resolutions[this.map.getZoom() + 1]

is not the most elegant solution ...

fredj

12/12/06 10:11:34 changed by euzuro

  • keywords set to review.

12/21/06 07:45:37 changed by openlayers

  • attachment MouseDefaults_2.js.diff added.

cleaner version: change Map getResolution to accept an optional zoom level. fredj

03/08/07 17:32:51 changed by sderle

  • owner set to sderle.
  • status changed from reopened to new.
  • milestone set to 2.4 Release.

fixed by r2548.

03/08/07 17:33:11 changed by sderle

  • status changed from new to assigned.

actually not fixed yet.

03/22/07 12:42:47 changed by sderle

  • keywords deleted.

03/23/07 13:07:45 changed by sderle

  • status changed from assigned to new.

During the hack week, I ran right past this comment (extracted from MouseDefaults.js into Handler/MouseWheel.js) without paying any attention to it:

// add the mouse position to the event because mozilla has a bug

// with clientX and clientY (see https://bugzilla.mozilla.org/show_bug.cgi?id=352179)

// getLonLatFromViewPortPx(e) returns wrong values

Caching the mouse location on mouse move works around this -- in fact, this is what MouseDefaults used to do, only it's done in the MouseWheel handler now. Also fixed the math in Control.Navigation. See the attached patch.

03/23/07 13:09:33 changed by sderle

  • keywords set to review.

03/23/07 13:11:03 changed by sderle

  • attachment 341.patch added.

03/23/07 22:55:05 changed by euzuro

all tests pass in FF and in IE6. i dont know much about the handlers code, but this seems like a reasonable patch. maybe run it by tschaub or cr5. looks good by me though.

03/24/07 19:13:16 changed by crschmidt

  • status changed from new to closed.
  • resolution set to fixed.

Committed in r2877. Good work, brings back functionality that we lost in the migration to the handlers code.

07/05/07 17:04:26 changed by euzuro

  • keywords deleted.