Inconsistent behavior of slider widgets

[Lars Karlitski]

In gtk+, left-clicking on any point inside the bar of a slider widget moves the thumb one step towards that point. The thumb can be moved to a specific point directly by middle-clicking that point on the bar.

In Ubuntu, some slider widgets have been altered to always jump to the clicked point directly, regardless of the mouse button that was pressed.

This is inconsistent and confusing, especially when sliders in the same app behave differently. For example, the mouse, keyboard, brightness, and accessibility settings in System Settings use the gtk+ style slider, while the sound and appearance settings use the other style.

Furthermore, this kind of change should not be made inside applications, but in gtk+ itself (even if the two kinds of behaviors are desired).

Assigning to Christian Giordano, as he's the bug contact on bug #898611, which made me aware of this issue.

[Lars Karlitski (larsu)]

I can't add ayatana-design as being affected by this bug. Can someone with the appropriate rights please do this for me?

[Charles Kerr (charlesk)]

The flipside to this consistency issue is that many users reported accidentally turning their volumes up to 0% or 100% by using the standard GTK+ slider behavior when one left-click-and-holds. If you click at the midpoint mark in a volume slider, you probably aren't expecting the volume to keep moving past 50% to either 0% or 100%...

[Matthew Paul Thomas (mpt)]

There are three possible behaviors here, when you press down in a slider trough between the thumb and one end.

(1) Move in steps towards that end, up to and right past the pointer, stopping at the end. This is what upstream GTK does.

(2) Move in steps towards that end, but only up to where the pointer is, and stop there. This is what Windows does (tested in Windows 7).

(3) Move the thumb immediately to where the pointer is, and allow dragging. This is what Mac OS X does (tested in 10.8 preview).

I don't know of anyone who thinks that (1) is a good idea, and it causes the accidental silence/blaring that Charles describes. But Lars is right, it shouldn't be changed piecemeal, it should be changed in GTK for every slider.

The advantage of (2) are that it's consistent with how standard scrollbars behave. (OS X has a setting for whether scrollbars should do the equivalent of (2) or (3), but (2) is the default, and scrollbars are hidden by default anyway.)

The advantages of (3) are that it's consistent with how scrub bars behave, such as in a music or movie player (though there are many fewer scrub bars than scrollbars); and that it allows immediate dragging to fine-tune the setting, without first having to release and re-click.

I prefer (2), though not strongly -- I'd be happy with either (2) or (3).

[Matthew Paul Thomas (mpt)]

So, let's try implementing (2) in GTK, and removing the custom code from the Sound and Appearance panels and IDO.

[Christian Giordano (nuthinking)]

I agree that option 1 is definitely the worst. I am inclined to option 3 simply because it is a standard behavior on the web (and in many other places, even GNOME uses it in the sound menu!). It is also more touch friendly.
I don't think sliders and scrollbars should necessary be so consistent (two very different beasts), but, as mpt says, our scrollbars are hidden anyways.

I discussed the matter with the people in GNOME and they actually deliberated for option 3 for sliders and also scrollbars (preserving the consistency). Clearly, I am not sure about the latter choice, but this is what our patch should do to get accepted. As said few times, this doesn't affect us.

[Matthew Paul Thomas (mpt)]

If by "deliberated for option 3" you mean "decided on option 3", then great, let's submit it upstream if it's not done already. One less patch to carry in the long run, and simpler code in three other places.

[Christian Giordano (nuthinking)]

@mpt, yep. That's what I meant. In italy we use that verb for new laws or court outcome. Evidently in English is not! ;)

[Lars Karlitski (larsu)]

Could we please get a feature freeze exception for this in gtk3?

This would unify slider behavior again and we could get rid of the ugly "act-as-if-middle-button-was-pressed" hacks in IDO and gnome-control-center.

I've submitted the patch upstream at https://bugzilla.gnome.org/show_bug.cgi?id=563688. GNOME designers support the change, so it has good chances of being accepted.

The package with my patch builds and works as expected. I've been running it for a bit on my system and tested every slider I could find, in particular all default applications.

[Martin Pitt (pitti)]

UIF -wise this seems fine for me, consistency is always good, and almost a bug fix anyway. Approved.

[Christian Giordano (nuthinking)]

@pitti yay! :)

[Sebastien Bacher (seb128)]

gtk 3.5 fixes the toolkit side of the issue, we just need to drop the hacks in quantal and that will be sorted

[Iain Lane (laney)]

totem and rb are both fixed upstream. I don't know about the others.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-control-center - 1:3.4.2-0ubuntu11

---------------
gnome-control-center (1:3.4.2-0ubuntu11) quantal; urgency=low

  * debian/control.in:
    - updated clutter requirement to match the configure version
  * debian/patches/96_sound_nua_panel.patch:
    - drop hacks and merge upstream changes for mouse scrolling (lp: #953757)
  * debian/patches/git_sound_sliders.patch:
    - "sound: Fix mouse scrolls on sliders"
  * debian/patches/git_update_keyring_password.patch
  * debian/source_gnome-control-center.py:
    - updated for python3, thanks Edward Donovan (lp: #1013171)
  * debian/UbuntuLogo.png:
    - updated logo for 12.10 (lp: #1035501)
 -- Sebastien Bacher <email address hidden> Fri, 24 Aug 2012 18:57:15 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package totem - 3.4.3-0ubuntu2

---------------
totem (3.4.3-0ubuntu2) quantal; urgency=low

  * debian/patches/git_no_browser_slider_hack.patch,
  * debian/patches/git_no_slider_hack.patch:
    - git patch, drop hack which was breaking "click to jump" behaviour
      with gtk 3.5 (lp: #953757)
  * debian/patches/git_use_keywords.patch:
    - backport upstream patch to set keywords in the desktop entry,
      it makes easier to find totem in the unity dash or gnome-shell
      (lp: #976624)
 -- Sebastien Bacher <email address hidden> Fri, 27 Jul 2012 15:47:52 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package rhythmbox - 2.97-1ubuntu4

---------------
rhythmbox (2.97-1ubuntu4) quantal; urgency=low

  * debian/patches/git_scale_click.patch: git patch, drop hack which was
    breaking "click to jump" behaviour with gtk 3.5 (lp: #953757)
 -- Sebastien Bacher <email address hidden> Mon, 27 Aug 2012 17:58:13 +0200

[Launchpad Janitor (janitor)]

This bug was fixed in the package ido - 12.10.1-0ubuntu1

---------------
ido (12.10.1-0ubuntu1) quantal; urgency=low

  * New upstream release:
    - fix inconsistent slider behavior (lp: #953757)
 -- Sebastien Bacher <email address hidden> Tue, 28 Aug 2012 13:49:28 +0200