GNOME Bugzilla – Bug 475509
Mouse scrollwheel browses, should move the view
Last modified: 2008-04-08 11:39:21 UTC
When in 'detail view' with a single image shown, a mouse scrollwheel action browses throught the other images of the directory. This is different to other applications (word processor, web browser, etc.) and thus very confusing. I suggest that scrolling with the mouse wheel should acts like in does in other applications: * If the image is too large for the screen and the right scroll bar is shown, using the mouse scrollwheel should move the view up and down. * If the image fits on the screen, using the mouse scrollwheel should do nothing. Thanks for the great work on gThumb.
I agree that one doesn't expect the mouse wheel to browse in that situation. But I think that the wheel should be used to zoom, moving the image around should be done by dragging. Just my 2 Cents.
Some background: Everyone seems to have a different idea about what the mousewheel should do - zoom, scroll, navigate... The HIG says the wheel should scroll, and ctrl+wheel should zoom. However, many image viewers use the wheel to navigate (browse). This was added to gthumb by popular demand (bug 131416). I find it nice to have a quick-browse method, personally. Some people have suggested different functions for the wheel in different modes or configurability, but Paolo, the main developer, prefers to keep it simple where possible (see bug 131416). It's impossible to please everyone on this issue... - Mike
Well, I can see the problem. A configuration option which defaults to the current way couldn't hurt though.
Thanks for your replies. Also thanks, Michael, for providing the links to the history of the change. I agree that everybody has a different idea what's best and that it's impossible to please everyone. So, let's go back to basic reasoning: * HIG complience: I'm all for violating usability principles when it makes sense (for instance, if these principles lead to unexpected behaviour). But this is not the case here. So, GThumb should be HIG complient. * Usability: A few weeks ago, I showed a friend of mine an image. She's not familiar with "modern" images viewers. When she used the mouse wheel, the image suddenly disappeared. She was confused and was afraid that she made a mistake. This behaviour is obviously not usable. I tried to get used to it for some weeks now, but I am still confused whenever I used the mouse wheel. * Marketing consideration: I like GThumb because it's a classical image viewer. Let's say, ACSee with a GNOME touch. To me, this is the major "sales" argument. Additionally, if there's already many other image viewers with such a function, people who like this default behaviour could switch. * Possible solution: The usual problem of not being able to please everybody does not really apply here. Just make "scroll" the default action, "zoom" the action for Ctrl+Wheel, and "navigate" the action for Ctrl+Shift+Wheel (or Ctrl+Alt+Wheel). Then, no additional option is needed in the preference dialog which is a good thing, usually. Maybe these reasons help to find a decision on the issue.
Was this fixed or not? In http://gthumb.sourceforge.net/ , I can read in the feature descriptions: "zoom in/out with mouse wheel;" Using ubuntu hardy, I open a single picture with gthumb (nautilus > open with gthumb), scroll the wheel and unexpectedly I am shown another picture that was in the same folder. IMHO, this is a totally awkward behavior, which seems more like a bug since it is contradictory with the feature description. Too bad I can't find the way to change this... hints are welcome. * Added support for displaying remote locations. * Added red-eye removal tool. * Added a filter bar, to limit displayed images. * Added thumbnailing and player-launching for videos and audio files. * Added programmable hotkeys. * Added the ability to manually specify photo print sizes. * Added a zoom-to-width mode. * Added sort by comment and sort by Exif DateTime tag. * Adds support for multiple auto-detected cameras, or multiple modes for single cameras. * Enhancements to the crop dialog: added undo/redo support; allow to crop multiple times without exiting the dialog; allow to switch on/off the selection mask; zoom in/out with mouse wheel; zoom keeping the center of the image visible. * Allows file extension to be changed when bulk-renaming. * Added "reset Exif orientation tag" tool. * New re-size options in web exporter to allow equal landscape and portrait image sizes.
Just to mention that all other linux image viewing apps I've in my linux box (eye of gnome, f-spot, digikam/showfoto) actually do implement zoom on scroll wheel. From a HIG perspective, I'd think it would be better to keep linux desktop apps consistent with themselves, instead of trying to mimic some random Windows app behaviour. Yes I've never used acdsee and I doubt the average windows desktop user has ever used it either.
It hasn't been changed. The changelog entry only talks about the crop dialog.
I was a supporter of 'the mousewheel should scroll the image', however if you think about it the mousewheel can only scroll the image vertically and not horizontally, so it can only be usefull in the rare case the image fits horizontally but not vertically, in all other cases you are forced to use other ways such as drag&drop or the keyboard commands or the navigation window. So I changed the mousewheel function because there are better ways to scroll an image. I think it's not important to be consistent with other applications or to be HIG compliant on this specific issue, because the current behavoir is more usefull than the previous one.