GNOME Bugzilla – Bug 79384
when zooming, center on mouse pointer or edges of the image
Last modified: 2007-05-27 13:35:13 UTC
when I have a selection or floating selection, and I zoom in, you should zoom in toward the selection, since that's obviously what I'm working on. Instead, you always zoom in toward the center of the window, and I have to scroll to whereever the selection was. This kind of behavior is conceptually related to bug 78732 ("don't paste off screen".)
I don't know if this should be marked as a bug (usability) or as an enhancement... Because the solution is not trivial: if the selection is a convex, connected shape that is smaller than the size of the visible area (at the current zoom level), then zooming towards the center of that area is relatively easy to do and this is probably what the user expects. On the other hand, if the selection is made of several disconnected parts, or is a non-convex shape, then the "center" of the selection (probably computed as the center of the bounding rectangle) may not be what the user expects. Especially if the selection is already larger than the window: in this case, it is probably better to zoom towards the center of the window, not the center of the selection. The problem would be even worse if the selection is completely outside the window and the user is viewing another part of the image at a high zoom level: zooming in should not re-center the window on the selection because this would confuse the user who probably wants to look at something different. I think that if any part of the selection is already off-screen (no matter how small this part is, compared to the whole selection), then it is better to use the center of the window instead of the center of the selection. But when the selection is entirely visible in the window, then zooming towards the center of the selection could be interesting.
Yeah, there are definitely some difficult margin-cases here. Your comment about "if any part of the selection is already off-screen" reminded me of something else I've been puzzling over, which is kind of related... Something that happens to me a lot is that I'm trying to work on something right at the edge of the image (with nothing necessarily selected) and I zoom in, and of course now the edge isn't visible any more, so I have to scroll. So I was thinking, maybe it would make sense for there to be some kind of "edge gravity"? Like, if the viewport is smaller than the image, and we are scrolled all the way in one direction, and we are zooming in, then remain scrolled all the way in that direction. I'm not totally sure that this would feel right, but it might be worth thinking about. Perhaps if there is a selection that is partially out of the viewport, then when zooming in, the row/column that is at the edge of the viewport should remain at the edge of the viewport? Adding a lot of special cases like this is always tricky; if you can really predict what the user is looking at, then it's exactly what they expect, but if you predict wrong, then they don't understand what's happening. There's a fine line between DWIM and violating the principle of least astonishment, and I don't know which side of that line this stuff is on.
So if we follow the DWIM way (or the DWJWZM way), we should try to do the following when zooming in: 1 - If a selection is active and it is entirely visible, then select the center of the selection (or the center of the bounding rectangle) as the reference point. 2 - If a selection is active and is partially visible and crosses one or two edges of the viewport that are not opposite edges, then have an "edge gravity" these edges. 3 - If no selection is active and the image is partially visible and one or two edges of the image that are not opposite edges match the edges of the viewport, then have an "edge gravity" on these edges. 4 - In all other cases, select the center of the window as the reference point. Well... This might work. Although the description of this thing looks a bit complex, it should not be hard to understand and maybe this would be more appropriate than the current behavior. I think that the conditions 1 and 3 would improve the usability of the GIMP for me. I am not sure about 2, though: sometimes the difference between 1 and 2 could be very small (a few pixels off the screen) and not always visible, especially when using a feathered selection. There could also be some confusion if a selection is made of several disconnected parts. Comments from other GIMP users or developers are welcome...
Other programs change the current tool to the zoom tool if you press a certain short cut key combination. This would allow you to zoom in on any part of the image without the hassle of moving the mouse pointer to the toolbox. Once the key combination is released, you get the previous tool back. I have always found that an extremely handy option and it's actually the only short cut I memorized for the Adobe products. (Command+Space for zooming in and Alt+Space for zooming out, IIRC.)
This would be a different way to solve the problem... The existing shortcut keys ("="/"-" for zooming in/out and "1" for the 1:1 ratio) could be kept, but with a different behavior: if the mouse pointer is inside the image window when the shortcut is used, then zoom in on that point. If the mouse pointer is outside the image window or if the zoom option was selected from the View or View->Zoom menu, then zoom in on the center of the window (current behavior). The zoom shortcuts would then behave as if the zoom tool had been used temporarily. Both solutions (behave like the zoom tool or the "DWJWZM" way, from which I like step 3 especially) could improve the usability. But we cannot have both at the same time, so we have to choose one and drop the other one. I will post a message on the gimp-developer list and ask for opinions. Maybe this could also be discussed on the gimp-user list and in the c.g.a.gimp newsgroup (the users would probably be interested in usability issues and they are often better at that than those who are deep in the code), but I will start with the developers.
Changes at the request of Dave Neary on the developer mailing list. I am changing many of the bugzilla reports that have not specified a target milestone to Future milestone. Hope that is acceptable.
I agree with Raphael: zoom centered on mouse position for the keyboard shortcuts is the correct way to do this. Most Apple Mac paint programs had this behaviour, and it's really intuitive once you've realised what its doing.
*** Bug 94206 has been marked as a duplicate of this bug. ***
I would like to have jwz's opinion on this: can we change the summary of this bug report to say: "when zooming, center on mouse pointer"? As I wrote above (more than one year ago - gosh!), the solution would be to center on the mouse pointer if the pointer is inside the image window and to use the old behavior if the pointer is outside.
That might be good enough; it's hard to say without having tried it. I'm a little worried that this wouldn't have the "edge gravity" properties we talked about, but maybe that would turn out to not be an issue.
We could try to implement this in the following way: - if the mouse pointer is inside the window, use it as the center point - if the mouse pointer is outside the window or if the View->Zoom menu was used, then do the following: - if one, two or three edges of the image are visible, then zoom in their direction ("edge gravity") - if zero or four edges of the image are visible, then zoom towards the center of the window (similar to the current behavior) That would give us both features, and it might even be easy to understand.
What I wrote above about the number of edges is a bit confusing. Here is a revised algorithm: - If the mouse pointer is inside the window, use it as the center point - If the mouse pointer is outside the window or if the View->Zoom menu was used, then consider each axis (X or Y) separately. For each axis: - If exactly one edge of the image is visible (i.e., either the minimum or the maximum value for that axis), then zoom towards it. - If zero or two edges are visible, then zoom towards the middle of the visible part of that axis.
*** Bug 139875 has been marked as a duplicate of this bug. ***
I've implemented this in my tree and played with it a bit and I'm not sure if I like the behaviour. Sometimes it makes sense but often it is just confusing. The mouse simply isn't always in the right location. Perhaps we should better pick up the suggestion made in comment #4. We could change the Space-pushes-Move-tool feature to Space-pushes-Zoom-tool.
Do you have a patch that could be tested? I am interested in the edge behaviour and I would like to test if it feels right or not. About Space-pushes-Zoom-tool: do you think that it would work well? If I understood comment #4 correctly, it looks like Adobe is using Ctrl+Space and Alt+Space as shortcuts instead of "+" and "-", but it is not pushing a tool. In our case, the user would have to keep Space pressed and then click or Ctrl+click in order to zoom in/out. Space+Ctrl+click might be a bit awkward. This is different for the move tool that is currently assigned to the Space bar, because the modifier (Shift) is not used as often.
Photoshop uses Ctrl-Space because they use Space is used to push the move tool. And yes, Photoshop sortof pushes a tool, it's not comparable to the +/- shortcuts.
sven, you said you didn't much like the result.... to improve it, please consider that the zoom-centered-on-pointer behavior is most powerful/useful (i think) when using the mouse wheel to zoom in and out. it's an alternative to panning...zoom out, point, zoom in. To get that behavior right, zooming in via mouse wheel should sample the pointer position at the first zoom-in-via-mouse and then ignore the pointer position for successive zoom-ins-via-mouse unless the pointer is repositioned. -- stig
I am really much confused with the discussions. can anybody please explain me this in comparison to gqviews way of doing it? Thanx in advance.
Centering zoom on the mouse cursor is probably a good thing to do if the zoom is caused by the mouse wheel. If however the keyboard shortcuts or menus are being used, then we cannot assume that the mouse cursor is anywhere close to the point the user zooms in to. My suggestion is that we implement this behaviour only for zooming with the mouse wheel.
2005-04-13 Sven Neumann <sven@gimp.org> * app/display/gimpdisplayshell-callbacks.c * app/display/gimpdisplayshell-scale.[ch]: when using Ctrl-wheel to zoom in/out, center on the mouse position (bug #79384). Even though this bug report had other suggestions than the one I implemented now, I am going to close this as FIXED. May a new report be opened if it turns out that further changes are desirable.
I found out what was wrong with my implementation. The request to center on the mouse position was misleading. The desired behaviour is to keep the point under the mouse cursor fixed (if possible). I've changed the implementation now and figured that this works so well that I enabled it for all zoom actions.
Will probably need some more work because this doesn't work well if zoomin is activated from the menus. We will have to special-case this.
2005-04-14 Sven Neumann <sven@gimp.org> * app/display/gimpdisplayshell-scale.c (gimp_display_shell_scale): hack around to find out whether we should pass the pointer location or the center of the display to gimp_display_shell_scale_to().
Needed another change: 2005-05-11 Sven Neumann <sven@gimp.org> * app/display/gimpdisplayshell-scale.c (gimp_display_shell_scale): also zoom on mouse position if the event originates from the canvas (see bug #79384).
*** Bug 441569 has been marked as a duplicate of this bug. ***