[linux-audio-dev] mouse wheel behavior and RFC: human interface guidelines

[John Check]

On Saturday 21 August 2004 06:48 pm, John Check wrote:
> On Saturday 21 August 2004 05:50 pm, Lee Revell wrote:
> > On Sat, 2004-08-21 at 17:33, John Check wrote:
> > > On Saturday 21 August 2004 04:41 pm, Lee Revell wrote:
> > > > On Sat, 2004-08-21 at 14:45, Thorsten Wilms wrote:
> > > > > Today might well have been the first time I used the wheel
> > > > > on common sliders, and it felt backwards!
> > > >
> > > > Agreed.  I can understand why Microsoft (and thus QT and GTK) chose
> > > > to
> > >
> > > The latter two, probably to fit in with the former. I think I may be
> > > missing something because my KDE sliders work like I expect.
> >
> > Hmm, someone else said QT sliders work the same way as GTK.  I don't
> > have KDE here so I can't tell.
> >
> > Probably this behavior can be set at widget creation time.
>
> It could be a windowmanager preference... Okay I see a "reverse scroll
> direction" option in the KDE3.3 mouse configuration dialog.
>
> How does this sound for a test..
> I'll flip the preference, logout, log into a non KDE session, then see what
> happens with a KDE app vs a QT app.
> I have GNOME installed, but I generally don't use the desktop. If somebody
> is a regular user and a similar option exists (I'm thinking it's probably
> in Gconf) I suggest doing the same on the GTK side.
>

Well, _that_ was enlightening.
I used Kmix for the sliders.
I flipped the setting in KDE and it took effect immediately contrary to the 
request to log out and back in again.
I logged out and logged into GNOME using metacity as a WM and fired up Kmix.
It worked like it originally did before flipping the KDE scroll reverse 
option.
The GNOME mouse configuratorizer didn't have a scroll toggle, but the main 
menu had "Control Center" at the toplevel, so I opened it.
It was the KDE control center.
I checked the mouse scroll option and it was in "reverse", so I inverted it.
The Kmix sliders were now inverted. Apparently it sets relative to whatever 
the window manager is doing when you start the CC applet. Since it was a 
different windowmanager it probably didn't read the defaults on KDE side.
For kicks I tried it against the GNOME volume control applet and it was 
consistent with the KDE app when changing the setting. Looks like it uses the 
same mechanism WRT the windowmanager, but that doesn't tell us anything about 
individual apps. Perhaps there is already a guideline somebody didn't apply.

I didn't try a plain QT app or other widget set, and I kind of forgot what 
specific app kicked off this question, but that's the deal with Kmix and 
whatever the GNOME mixer applet is called.

> > Lee