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 666121 - mouse pointer should be hidden until used
mouse pointer should be hidden until used
Status: RESOLVED DUPLICATE of bug 687791
Product: gnome-shell
Classification: Core
Component: login-screen
3.1.x
Other Linux
: Normal normal
: ---
Assigned To: Ray Strode [halfline]
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2011-12-13 19:57 UTC by Ray Strode [halfline]
Modified: 2012-11-13 13:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ray Strode [halfline] 2011-12-13 19:57:27 UTC
[14:49:01] <steph> anyway, the bottom right corner (even with the margins) if a bit weird
[14:49:11] <steph> it leaves me with the feeling that my screen resolution was misdetected
[14:49:32] <steph> and it's not really natural, is it?
[14:49:52] <halfline> i don't know
[14:50:13] <steph> jimmac, garrett mccann input?
[14:52:02] <mccann> halfline: I hate that the pointer goes to the corner
[14:52:28] <mccann> especially when it spins
[14:52:36] <mclasen> the spinning is irritating, indeed
[14:52:38] <mccann> it is much better to hide it until it is needed or something
[14:52:44] <mclasen> we should hide it until it gets touched
[14:52:48] <mccann> it is stupid that it warps to the corner
[14:53:04] <halfline> okay we can hide it until it's moved around
[14:53:21] <halfline> where do you put it when it's time to come into being ?
[14:53:27] <halfline> center?
[14:53:34] <halfline> centered over focused user in list ?
[14:53:34] <mccann> seems right to me
[14:53:39] <mccann> especially since that is where it will be used
[14:53:57] <steph^ make the pointer only appear when you move your mouse, even on desktops?
[14:54:01] <halfline> which? center of monitor or centered over list item ?
[14:54:52] <mccann> hard to imagine the difference have to see it but I think monitor symmetry probably makes sense
Comment 1 Ray Strode [halfline] 2011-12-13 20:13:29 UTC
Jon points out that we should consider hiding the pointer on idle as well.
Comment 2 Ray Strode [halfline] 2011-12-13 20:22:06 UTC
Note, another goal of his is to stop using the mouse pointer for indicating pending activity.  See related bug 652066
Comment 3 drago01 2011-12-20 18:40:51 UTC
(In reply to comment #1)
> Jon points out that we should consider hiding the pointer on idle as well.

I am not really against it but I fail to see the point .. or the problem that is being solved here.
Comment 4 Ray Strode [halfline] 2011-12-21 16:16:29 UTC
Well, let me start by saying this stuff isn't fundamental or critical, but it is polish.

First the problem: the pointer can end up in awkward places.  

We've had bugs in gdm and screensaver where it's been put smack dab in the middle of two monitors causing confusion all around since it's essentially random which monitor it will end up on initially.  This is aggravated by the fact the pointer location is often used to figure out what monitor things should show up on (I guess because it's a crude approximation of what monitor the user is looking at)

It's not just multi-monitor setups that the pointer placement can be problematic for though. GDM has had bugs where the pointer ends up smack dab in the middle of the user list over a user and then the greeter starts up with a tooltip blocking it.

So now, we place the pointer in the lower right hand corner of the screen away from any of the edges or the middle of the screen.  This causes a new issue: it looks unnatural and people wonder why it's down there.

So that's the basic problem, now to rationale behind the proposed change:

The pointer is an extension of the mouse. It's the virtual half of pointer/mouse pair.  The pointer's primary existence is to provide feedback to users when they move their physical mice (or touchpads or trackpoints or whatever).  That feedback is normally only needed when the mouse is actually being moved, though. Furthermore, it often gets in the way when not moving the mouse.  Some apps like movie players explicitly hide the mouse after the user stops moving it, but it's sort of silly to have per-app special case code, when the problem is a general one: the pointer isn't needed when the user isn't moving the mouse, and it isn't wanted when it blocks a part of the screen the user is looking at.

Also, gnome-settings-daemon has code to hide the mouse pointer on tablet devices.  This is because, the pointer is a mouse feedback mechanism and it's not really appropriate on those kinds of devices (although touch feedback has its own merits, but that's an independent problem with potentially different solutions).

So that's the rationale in broad strokes.  Hope it make sense.
Comment 5 drago01 2011-12-22 11:09:32 UTC
(In reply to comment #4)
> Well, let me start by saying this stuff isn't fundamental or critical, but it
> is polish.
> 
> First the problem: the pointer can end up in awkward places.  
> 
> We've had bugs in gdm and screensaver where it's been put smack dab in the
> middle of two monitors causing confusion all around since it's essentially
> random which monitor it will end up on initially.  This is aggravated by the
> fact the pointer location is often used to figure out what monitor things
> should show up on (I guess because it's a crude approximation of what monitor
> the user is looking at)
> 
> It's not just multi-monitor setups that the pointer placement can be
> problematic for though. GDM has had bugs where the pointer ends up smack dab in
> the middle of the user list over a user and then the greeter starts up with a
> tooltip blocking it.
> 
> So now, we place the pointer in the lower right hand corner of the screen away
> from any of the edges or the middle of the screen.  This causes a new issue: it
> looks unnatural and people wonder why it's down there.
> 
> So that's the basic problem, now to rationale behind the proposed change:
> 
> The pointer is an extension of the mouse. It's the virtual half of
> pointer/mouse pair.  The pointer's primary existence is to provide feedback to
> users when they move their physical mice (or touchpads or trackpoints or
> whatever).  That feedback is normally only needed when the mouse is actually
> being moved, though. Furthermore, it often gets in the way when not moving the
> mouse.  Some apps like movie players explicitly hide the mouse after the user
> stops moving it, but it's sort of silly to have per-app special case code, when
> the problem is a general one: the pointer isn't needed when the user isn't
> moving the mouse, and it isn't wanted when it blocks a part of the screen the
> user is looking at.
> 
> Also, gnome-settings-daemon has code to hide the mouse pointer on tablet
> devices.  This is because, the pointer is a mouse feedback mechanism and it's
> not really appropriate on those kinds of devices (although touch feedback has
> its own merits, but that's an independent problem with potentially different
> solutions).
> 
> So that's the rationale in broad strokes.  Hope it make sense.

Yes that makes sense, thanks.
Comment 6 Bastien Nocera 2012-04-05 16:40:31 UTC
Except that hiding the mouse pointer doesn't fix the bugs you mention. They will still show up in random location, because that's where they were when we hid them. The spinner sucking is a different problem, and that should be fixed before we even consider changing whether or not to hide the mouse pointer on idle.
Comment 7 Ray Strode [halfline] 2012-04-05 16:42:19 UTC
when you hide it, you could warp it to its hiding place.
Comment 8 Ray Strode [halfline] 2012-11-06 19:17:32 UTC
This got refiled, so let's just dupe this one.

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