On 12 March 2010 10:35, Allan Day <[email protected]> wrote: > Though most widgets cannot be controlled through the mouse wheel, a > small number can (combo boxes, volume sliders and the window list, for > example), so it's not completely inconsistent to have this behaviour for > tabs.
If I can put in another opinion, I'd like the mousewheel behaviour removed for these widgets too. My app is a somewhat-spreadsheet-like image processing system. The main window is a scrolling view of a workspace which can contain images, matrices, sliders, combo boxes, and a lot of other stuff. Screenshot: http://www.vips.ecs.soton.ac.uk/index.php?title=Image:Screenshot-nip2-7.12.2.png It's nice to be able to scroll about the workspace with the wheel ... but also very dangerous. If one of the widgets that has mousewheel navigation comes under the cursor, suddenly scrolling stops and you start editing the workspace. Very annoying! Of course you can undo the change, but you don't always notice that it has changed something. As a result, the mousewheel is almost useless. I've had to implement my own slightly odd middle-drag-pan system instead. You get the same difficult behaviour in firefox when you are scrolling a page with an embedded flash object. If the flash object falls under the cursor while scrolling, suddenly scrolling stops and you start interacting with the flash player instead. In my opinion (though of course perhaps it's not worth much) I'd like to see the mousewheel just do one thing reliably. It should either just change widgets, or it should just scroll. Having it change behaviour depending on what happens to fall under the cursor, particularly when one of the things it does is to change what's under the cursor, is confusing and alarming. John _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
