Slider handle doesn't stop at mouse position when clicking outside of the handle

[Hernando Torque]

Binary package hint: indicator-sound

Example:

Pressing the mouse at position "x" (1), the volume decreases all the way down to vol_min (2). Clicking the same position again, the volume raises to vol_max (3). What I expect when clicking at "x" is, that the handle moves to exactly that position (4).

1. [------------x---------((()))--]
2. [((()))------x-----------------]
3. [------------x-----------((()))]
4. [----------((()))--------------]

If this is a design choice I'd like to know the reasoning behind it, because if I want vol_min/vol_max there's already a more efficient way to get it: clicking the dedicated buttons.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: indicator-sound 0.3.4-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.35-6.9-generic 2.6.35-rc3
Uname: Linux 2.6.35-6-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Sun Jul 4 11:18:17 2010
ProcEnviron:
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: indicator-sound

[Omer Akram (om26er)]

I think thats the intended behavior

[Vish (vish)]

When we change the volume in the sound preferences window by clicking on the slider. Its just one click and volume is increased/decreased to the position where it was clicked. Not in increments and no overshoots

However ,when we click on the scrollbars , it is an incremental page up or page down and it stops where the user is clicking. No overshoots here either.

If user clicks on a position in a slider , user wants to set the level/position there , either we do it in increments or in one shot. Doing it in increments can be useful , while increasing or decreasing volume to set the desired volume.
There is no reason for an overshoot.

[David Barth (dbarth)]

Moving to the central ayatana work list for the last 10.10 iteration.

[David Barth (dbarth)]

De-listing from the beta milestone, waiting for input from Conor on whether it is still worth fixing without impacting the release.

[Hernando Torque (htorque)]

I got to correct Vish: scrollbars do show the same behavior (eg. Gedit and Nautilus), while I've seen sliders that stop at the mouse position (like timelines in eg. Rhythmbox and Totem), don't react to clicks outside of the handle at all (The Widget Factory), or show the described behavior (Gimp).

[pfrenssen (pieter-frenssen)]

Often when you click on the volume slider button you don't "grab" it but it starts moving quickly towards max volume. This can be rather startling.

It happens when you click on the speaker icon in the notification applet, and then click directly on the volume slider button.

It does not happen when you click inside the popup window (eg. to the left of the slider) before clicking on the slider button.

[Vish (vish)]

Hernando Torque , Yea.. scrollbars in Nautilus/Gedit do the same.. But, I had tested in Firefox, which stops at the pointer.. Well that's another bug i guess. ;-)

[Bartosz Kosiorek (gang65)]

I think it will be much easier to change all GNOME sliders (it is using the same component).

[Hernando Torque (htorque)]

So... is this bug invalid? Does it need input from the design team?

[Chris Wilson (notgary-deactivatedaccount)]

I'm not able to reproduce the overshoot described in the original report. Instead, I observe an incremental increase/decrease in the direction towards the click until the slider reaches the cursor, at which point no further change is observed. Is this considered fixed or do we want to move the volume slider straight to the location of the click, instead of using these increments?

[Hernando Torque (htorque)]

I certainly can reproduce it in Precise.