After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 684570 - Setting « Content sticks to fingers » makes lifting the shield surprising
Setting « Content sticks to fingers » makes lifting the shield surprising
Status: RESOLVED DUPLICATE of bug 704050
Product: gnome-shell
Classification: Core
Component: lock-screen
3.5.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 693135 695440 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2012-09-21 16:56 UTC by Mathieu Bridon
Modified: 2013-08-20 09:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Mathieu Bridon 2012-09-21 16:56:16 UTC 
I set « Content sticks to fingers in G-C-C, as it just feels so much more natural on a touchpad.

However, now I have to scroll **down** to lift the shield **up**.

I think this particular action, lifting the shield, should always happen by scrolling up, no matter whether the « Content sticks to fingers » checkbox is checked or not.
Comment 1 Florian Müllner 2012-09-21 16:59:47 UTC 
I agree, and the same applies to other scroll uses like volume control - we should reverse the scroll direction in case natural-scroll is enabled and the device is a touchpad; unfortunately this requires completion of the XI2 port first ...
Comment 2 Greg K Nicholson 2012-11-29 23:50:49 UTC 
I think the lock shield interaction is arguably incorrect even for scrollwheel users.

Normally, scrolling up on the scrollwheel moves the viewport upwards relative to the content. The content therefore moves downwards on the screen.

Using a scrollwheel, the user never directly manipulates the content on the screen – they only move the view.

(By contrast, dragging up on the touchpad drags the content itself upwards.)

When the lock shield retracts, it moves upwards. This is what usually happens when scrolling downwards on the mouse.

I think we should *consider* swapping the scroll direction used to unlock, for both scrollwheel and touchpad users.

*

I found this bug because I came looking for the volume control bug Florian mentions in comment 1. However, after thinking through my comment in bug 684571, comment 1, I'm not entirely sure that the current interaction is wrong.

It feels wrong if I think of scrolling "up" and the volume going "down". However if I think of pushing "away" and the sound becoming "more distant", the current interaction becomes cogent.

(On the other hand, pushing away has always meant "louder" on mixing decks and "energise" on starships, and that familiarity is probably stronger than this logic.)
Comment 3 Matthias Clasen 2013-02-09 00:33:33 UTC 
*** Bug 693135 has been marked as a duplicate of this bug. ***
Comment 4 Florian Müllner 2013-03-08 13:00:03 UTC 
*** Bug 695440 has been marked as a duplicate of this bug. ***
Comment 5 Allan Day 2013-08-20 09:49:44 UTC 
Marking this as the duplicate, since the other bug has patches.

*** This bug has been marked as a duplicate of bug 704050 ***