kcombobox wheelmouse scrolling

[Thomas Zander]

On Sun, Sep 29, 2002 at 11:29:05AM -0600, Aaron J. Seigo wrote:
> On Saturday 28 September 2002 01:05, Stephan Kulow wrote:
> > The reason is that it's just too easy to change the combo
> > box value without an option to revert it. I think, having to
> > open the combo box and then beeing able to scroll in it
> > is easy enough and can't happen by accident.
> 
> i actually find it extremeley useful; you have no idea how much clicking being 
> able to scroll through combboxes saves me in an average day =)
> 
> the biggest problem seems to be on web pages where people are scrolling the 
> page using the mouse and the mouse gets "snagged" in a combobox... 
> 
> IMO the beauty solution would be something like this:
> 
> once scrolling a web page has started using the wheel, all wheel events 
> continue to scroll until the mouse has moved the manhatten length at which 
> point the event may be transferred to the widget beneath it (which may still 
> be the view).
> 
> this way, if the person is just scrolling a web page, it doesn't get snagged 
> up in any widget. but if they puposefully put their mouse over the widget, it 
> allows scrolling.

As Aaron is seen as someone keen on usability I want to put some counterweight
on his conclusions.

I don't believe the solution of automatic definition of scrollwheel-scope will
work; the solution presented (by Aaron) will be too subtile to become something
the user learns as logical. If the user does not learn the 'mental-model' behind
the GUI (s)he will not be able to forsee when to expect. In other words; the
user will sometimes get unexpected results, and loose confidence in the GUI.


> > The other problem is if you wheel mouse over konqueror's
> > location bar, it will load another page. The fact is that
> > changing a combobox has immediate effect, but a wheel
> > mouse shouldn't change anything but the view. 
> 
> the location bar in konqi should pass the scroll even through to the view, 
> just as scrolling on any of the other items in the tollbar does. i don't see 
> this alone as reason enough to labotomize all the other comboboxes. =)

So because the scrolling of the combobox has an immidiate effect you believe
it should not be possible to scroll (using the mousewheel)...
And what about comboboxes that have a javascript 'onchange' event?
And the comboboxes/spinboxes that immidiately effect a preview as seen in a
number of KCMs and dialogs?

I'm not sure I like either solution; but my pick is always for the one with
the simplest rules. The less rules a programmer comes up with on GUI behavior
the easier it is for a user to use.
So the best solution in usability is the one to disable all scrollwheel
activity in comboboxes. But that is a feature that none of us would like to
miss ;)

So in the spirit of the 
    'if the programmer can't decide; popup a dialog to ask the user' 
disable all comboboxes where the scope of a scrollwheel would be doubtfull.

In programmers speak; all comboboxes that are embedded in something that has
scrollbars.

Thanx for reading.
-- 
Thomas Zander   zander at planescape.com
We are what we pretend to be