Opened 12 years ago
Last modified 4 years ago
#8668 new enhancement
[ShowImage] Improved zoom button behavior
Reported by: | mmadia | Owned by: | leavengood |
---|---|---|---|
Priority: | normal | Milestone: | R1.1 |
Component: | Applications/ShowImage | Version: | R1/Development |
Keywords: | Cc: | mdisreali@… | |
Blocked By: | Blocking: | #8665 | |
Platform: | All |
Description
resize the window to fit the image (e.g., 1:1 size) if possible in this case, too. If the 1:1 size is larger than the current resolution, then scale the image to be a best fit.
Note: as of hrev44244, full screen can be entered with CMD-Enter, as well as double-clicking the content area.
Change History (12)
comment:1 by , 12 years ago
Blocked By: | 8665 removed |
---|---|
Blocking: | 8665 added |
follow-up: 4 comment:2 by , 12 years ago
comment:3 by , 12 years ago
I've been using the Mac image viewer Xee lately, and I like a lot of its features. The way it handles the window size is quite nice, and there is even an old forum post where someone says we should mimic Xee in ShowImage. Now that I've used it I can see that user's point. Now I don't think we need to copy it verbatim, but some of its user interface may be worth copying. I need to play with it more and document the behaviors and then I could see what makes sense with ShowImage.
follow-up: 5 comment:4 by , 12 years ago
Cc: | added |
---|---|
Summary: | Improved zoom button behavior → [ShowImage] Improved zoom button behavior |
The zoom button should only resize the window, not the image.
Once again, your suggested behavior seems to eliminate the possibility of a simple means for the user to get a maximized window.
Replying to humdinger:
If I may suggest another best fit option for the zoom-button: Do not resize the image 1:1, just resize the window to best fit around the currently displayed image. That way black borders are removed if possible. The 1:1 command already has a toolbar icon and menu item.
Sorry, I see no benefit of this behavior. Are you saying you want ShowImage to resize its window for each and every image in order to minimize black borders? That sounds like a lot of extra programming effort for something that should be done by the user.
Once again, the simplest zoom behavior that would benefit most users, is to go from the user set size to maximized.
comment:5 by , 12 years ago
Replying to Disreali:
Once again, your suggested behavior seems to eliminate the possibility of a simple means for the user to get a maximized window.
As mmadia noted, there are already simple means (like a double click) to switch to full screen. The only real downside of using the zoom button as general full screen button is that it is asymmetrical, ie. you can only use it to enter full screen, not to leave it.
However, a maximized window (the default behavior of the zoom button) is often not really useful. With ShowImage, in particular, I don't see a compelling reason to run it maximized.
Replying to humdinger:
If I may suggest another best fit option for the zoom-button: Do not resize the image 1:1, just resize the window to best fit around the currently displayed image. That way black borders are removed if possible. The 1:1 command already has a toolbar icon and menu item.
Sorry, I see no benefit of this behavior.
I like it :-)
Are you saying you want ShowImage to resize its window for each and every image in order to minimize black borders? That sounds like a lot of extra programming effort for something that should be done by the user.
Huh? The window will just be resized in order to show its full contents, exactly like what Tracker is doing. This helps to minimize the real screen estate ShowImage uses which can be very helpful if you want to open more than one image at a time.
Once again, the simplest zoom behavior that would benefit most users, is to go from the user set size to maximized.
In what way would a maximized window benefit the user? If you want to present the image, full screen is the best option, as the additional window decorations are distracting. If not, how is a maximized window helpful?
comment:6 by , 12 years ago
(GCI-2012 Participant) Haiku revision: hrev44702. Valid, but this is not a bug. While ShowImage can be made to reduce the black space, the user can simply resize the window size, or if the image is too big, use fullscreen and ignore the black space. One way to make resizing window size better is to snap the window size to the size of the image when it gets close to the size of the image. System: Haiku R1-alpha4 on Virtualbox 4.1.20 on windows 7 64 bit
comment:7 by , 6 years ago
How crazy would a three state (well sort of 2 and half states) zoom button be?
- First zoom button click, State 1: make window fit image, no image scaling (humdinger's idea.)
- Second zoom button click, State 2: make window maximized, scale image to fix exactly inside the maximized window (with black bars of course for images whose aspect ratio does not match the screen.)
- Subsequent zoom button clicks: toggle between State 1 and 2 (note, we would never go back to whatever the non-optimal original size was.)
This may require a bit of state handling in ShowImage to remember the State 1 size, position and image scale level, but otherwise should be easy enough.
I also suspect the Shrink to Fit and Zoom to Fit options will make this more tricky. I'd have to test and see what needs to be adjusted.
comment:8 by , 6 years ago
Sounds good to me. If you can pull it off without state confusion... :)
WRT to justify maximized windows == "fullscreen+GUI": Maximized windows may be useful (though quite seldom for my usage), because the image is max size and you still get to the menus (rotate, rate, and other options) and you see size and zoom factor in the status bar.
comment:9 by , 6 years ago
I don't like maximized windows. Keep it simple and apply the HIG rule: "zooming a window should pick the appropriate size that fit the contents".
So:
- If your image is small enough: 1:1 and fit the window to the image
- If the image is larger than the screen: maximize, fit image to window
- If the user already changed the zoom level: preserve the user selected zoom level, try to fit the window to the image at that zoom scale (going maximized if it doesn't fit)
Going further:
- If the window is "zoomed" and exactly fits the picture, changing the zoom level could automatically size the window accordingly
- However, if the window was manually resized or does not fit the image size already, changing the zoom level should not resize the window (and you get scrollbars)
I think this gives what the user expects in most cases?
comment:10 by , 6 years ago
I can get behind most of your idea pulkomandy. It seems fairly close to mine, except subsequent clicks on the window zoom button would do nothing if the window was already in the "ideal" zoomed state. Which is probably fine. I would expect the zoom button to end up maximizing the window most of the time since nowadays most digital camera or phone images are pretty high resolution. But if you are browsing smaller images or have a high resolution screen it would be nice if zooming made the window fit.
Regarding your going further section: at first I was going to reject the idea of changing the window size on image zooming, but the more I think about it, the more it makes sense. I can try adding it to see. Either way we need a routine in the code to resize the window to fit the image, so it is just a matter of calling that after an image zoom, or not.
What I like about this idea is it does not require maintaining any extra state (at least I don't think so.) You just look at the current size of the zoomed image, and resize the window to that, but no bigger than the screen size, and of course no smaller than the minimum window size.
There is one final wrinkle to all this: how should the window be moved if it will not be maximized? Should we try to keep it as close to where it is as possible, only moving it to avoid the window going off the screen (aka maintain the window tab as close to where it is?) Or should it always be centered on the screen? Or maybe it is resized around the center point of the current window, which makes a lot of sense when changing the window size on image zooming...
By the way, it is probably obvious, but I am discussing this in such depth so that a few of us can come to a consensus, I can implement that, and then code review will be just about code, not behavior.
Also, boy is it confusing talking about the window zoom button and also the zoom level of the image...
comment:11 by , 6 years ago
The ideal behavior for resizing the window is "what is under the mouse stays under the mouse". In most cases this means extending the window to the bottom/left, so that the toolbar and tab do not move.
However, if that results in the window being partially offscreen, it should be moved back in, so that it is flush to the screen border on one or two edges (or 3 or 4 if the picture doesn't fit and is scaled down).
The case of pictures with very wide or very high aspect ratio has to be considered, which creates some intermediate case (the image is scaled down to fit in one direction, and the window is then adjusted in the other direction to fit the scaled down image). What happens when you do that and then resize the window is left to the discretion of whoever implements this :) My guess would be that the image should be scaled up as you increase the size of the window until it reaches its 1:1 size, with scrollbars appearing in the other direction. But, whatever is more convenient will probably be ok, this is not a very common use case for me at least, and it is quite possible that I will change my mind after testing it in a few cases (thinking eg. scanned paper documents and panoramic pictures will have different needs...)
comment:12 by , 4 years ago
Milestone: | R1 → R1.1 |
---|
If I may suggest another best fit option for the zoom-button: Do not resize the image 1:1, just resize the window to best fit around the currently displayed image. That way black borders are removed if possible. The 1:1 command already has a toolbar icon and menu item.