GNOME Bugzilla – Bug 306110
Mouse wheel behavior should follow the HIG
Last modified: 2005-09-26 15:31:28 UTC
According to the HIG [1], ctrl-scrollwheel events should be treated as zoom change requests, not as double-stepped scroll requests. Cf. discussion on usability [2] and bug 79352 against Nautilus. [1] http://developer.gnome.org/projects/gup/hig/2.0/input.html#mouse-buttons [2] http://mail.gnome.org/archives/usability/2005-May/msg00125.html
This is fixed in Epiphany cvs since _yesterday_. You're too slow ;P What about the zoom directions? Should wheel-up zoom in or out? (Zooms out in Epiphany.)
From HIG: "Ctrl-scrollwheel-up should zoom into the window or control under the mouse pointer, and Ctrl-scrollwheel-down should zoom out".
Then we'd have an inconsistency with the zoom control on toolbar: place the mouse over it and use the wheel zooms: up zooms out, down zooms in. Should we re-arrange the entries in the zoom control from small->big to big->small ? (And then we'd need to make the same change in evince).
I don't know whether that is an important aspect, since the toolbar combobox order (small...big) seems to be quiet natural. Maybe can get feedback from usability folks?
ping.
Fixed in cvs.
There's no usability folks feedback yet :( Making the zoom control on the toolbar behave the same as the ctrl-mousewheel movements makes more sense to me than the current behaviour (wheel up zooms out, while ctrl-wheel up zooms in). Since an open drop down box (the list of zoom percentages) doesn't respond to mousewheel events this change won't introduce other inconsistencies.
Hmm... very hard to make a call on this one without getting feedback from 'real' users, I think. My suspicion is that most users will have a 'favourite' way to zoom in our out: either they'll use the combo box (with or without the mousewheel), *or* they'll use the mousewheel over the main pane. In which case, I'd agree with Christian that it's probably fine to leave the combo entries in their 'natural' order. But I could be wrong :)