It zooms into the center of the screen indeed.
This is how photoshop, KStars and others do it. But checking Google Earth (without a mouse wheel but using the right mouse button pressed) I realize that Google Earth probably does it the way you're describing it.

We need to discuss this. I think this is more a wishlist item than a bug. :-)

Thanks for your suggestion.

Torsten

google maps and openstreetmap.org and inkscape all zoom in where the mouse is.

If you want to make an argument for doing it the way people are used to, we need to do what google maps does. The general population doesn't use photoshop.

If you want to make an argument for it being nice to use, it needs to zoom in at the mouse. This makes it about 3x faster to get to the city/street you want.

Well, there are three things I take into account:

1. Consistency with the other KDE applications (okular, khtml, kstars, krita, etc., all those centerzoom on using the scrollwheel)
2. Consistency with other applications of the same kind where it makes sense(Google Earth, Virtual Earth, WorldWind, etc.  all those centerzoom on scrollwheel moving)
3. Usability improvements

Currently Marble is consistent in its behaviour with all existing other KDE applications and virtual globes. 
There seems to be a similar wishlist item for okular.
I've just tried the feature you are suggesting on google maps and openstreetmap. I like it and I see why you want it.

I'll talk to the other KDE application authors to see whether we'll be able to deliver the feature for all KDE applications for KDE 4.3.

If you're a programmer I'd appreciate a patch that implements the feature (it's not too hard to do and I'd help you if you got questions ...)

While thinking about this problem I realized today in the morning that the implementation of this feature for Marble's current default navigation mode isn't as easy as I thought:

For usability reasons we allow only 2 degrees of freedom for the rotation in spherical projection: Rotation in latitude and longitude. This ensures that the pole axis is always arranged vertically and that north is always up (or down).
In the settings dialog this mode is called "Keep planet axis vertically".

In the future we plan to additionally support 3 degrees of freedom for the rotation of the globe (like Google Earth does it these days). This mode will be used for advanced users and if a GPS device is attached and Marble is used to track the position (in that case the driving direction would be always pointing upwards). In the settings dialog that mode will be called "Follow mouse pointer".

For the "Follow mouse pointer" mode we'd be able to replicate the suggested zoom behaviour exactly (once it's implemented). For the "Keep axis vertically" mode however we'd only be able to have a behaviour that would keep the position that is being zoomed at only approximately under the mouse pointer (as the two degrees of freedom don't allow to keep the position fixed while zooming).

I don't see this as a problem but I just wanted to mention it in advance.

Created attachment 35102 [details]
Centers the map at the cursors position, when zooming with the scroll wheel.

My first patch for marble, that makes the scroll wheel zooming work as it does in google maps and openstreetmap/openlayers.

Mattias, thanks for the patch. I'm only missing one thing: Currently this does make the place under the mouse the new center of the widget. Instead the (geo) position under the mouse should stay at the same (screen) position.

In summary:
Currently: geo position at center stays unchanged
Patch: geo position at mouse becomes screen center
Desired: geo position unter mouse stays unchanged

Created attachment 39623 [details]
wheel-zoom-to-mouse-pos.diff

Updated version of the patch. Mostly whitespace and filename changes. One semantic change: Toggled if ( !isValid ) to if ( isValid )

Created attachment 39624 [details]
marble-mouse-geopos-stays.diff

This patch fixes the issue mentioned above.

Please test it and comment: I think it leads to a noteworthy usability improvement and should go in, but won't commit directly as no consensus was reached yet.

Created attachment 39625 [details]
make zooming smooth

Neeeat :-)

The previous implementation was still a bit shaky, so I did a tiny little change to make the zoom more smooth. Thanks a lot for making this work everyone involved!

I've committed the current patch. Now we'd like to see the cross hair move to the zoom target position during zooming ... this part of the fix still needs to be done ...

SVN commit 1071370 by nienhueser:

Introduce a focus point (move-invariant point when zooming) in ViewportParams, used by the default input handler and the crosshair plugin to indicate a non screen-centric zoom action to the user.
CCBUG: 177591


 M  +3 -0      lib/MarbleWidgetInputHandler.cpp  
 M  +34 -1     lib/ViewportParams.cpp  
 M  +29 -0     lib/ViewportParams.h  
 M  +9 -3      plugins/render/crosshairs/CrosshairsPlugin.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1071370

With the last patch committed to trunk I consider this bug fixed. Fix will get backported to KDE 4.4.

SVN commit 1071394 by nienhueser:

Backport of commits 1070837, 1071370 and 1071389:
- Initial fix by Mattias Dalkvist and Dennis Nienhüser. This is neat! :-)
- Introduce a focus point (move-invariant point when zooming) in ViewportParams, used by the default input handler and the crosshair plugin to indicate a non screen-centric zoom action to the user.
- Export class AbstractProjection since it is now used by the CrosshairsPlugin.
BUG: 177591




 M  +29 -2     lib/MarbleWidgetInputHandler.cpp  
 M  +2 -1      lib/Projections/AbstractProjection.h  
 M  +34 -1     lib/ViewportParams.cpp  
 M  +29 -0     lib/ViewportParams.h  
 M  +9 -3      plugins/render/crosshairs/CrosshairsPlugin.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1071394