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 657175 - better feedback for long presses
better feedback for long presses
Status: RESOLVED OBSOLETE
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-08-23 15:35 UTC by Ray Strode [halfline]
Modified: 2021-07-05 14:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ray Strode [halfline] 2011-08-23 15:35:31 UTC
There are a few places in the shell where a "long press" will bring up a context menu (for instance the dash, and some proposed changes in bug 652183. This a very important feature for tablet users and users with 1 button mice.

It suffers two problems, though:

1) When the user is in the middle of a long press, they don't get any feedback that it is being evaluated as such.  This could lead the user to prematurely releasing to initiate it again, and then subsequently, accidentally initiating a short click. Maybe some sort of subtle animation would help here? The ripples?

2) There's no obvious way to know where long presses are allowed.  Is there some consistent thing we could do on prelight?  Granted, not all tablets support hovering. Some other way to clue the user in?
Comment 1 Miguel Vaello Martínez 2016-05-06 10:39:45 UTC
(In reply to Ray Strode [halfline] from comment #0)
> There are a few places in the shell where a "long press" will bring up a
> context menu (for instance the dash, and some proposed changes in bug
> 652183. This a very important feature for tablet users and users with 1
> button mice.
> 
> It suffers two problems, though:
> 
> 1) When the user is in the middle of a long press, they don't get any
> feedback that it is being evaluated as such.  This could lead the user to
> prematurely releasing to initiate it again, and then subsequently,
> accidentally initiating a short click. Maybe some sort of subtle animation
> would help here? The ripples?
> 
> 2) There's no obvious way to know where long presses are allowed.  Is there
> some consistent thing we could do on prelight?  Granted, not all tablets
> support hovering. Some other way to clue the user in?

I think that this old issue should be revisited due the "inevitable" touch desktop/tablets invasion. In my opinion, the Android +5.0 solution could be a good starting point, especially to resolve the long press feedback described in point 2.
Comment 2 GNOME Infrastructure Team 2021-07-05 14:14:56 UTC
GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.