Mouse pointer should disappear when keyboard is in use and mouse isn't

Bug #16492 reported by Matthew Paul Thomas
282
This bug affects 56 people
Affects Status Importance Assigned to Milestone
GTK+
Expired
Wishlist
One Hundred Papercuts
Triaged
Low
Unassigned
gtk+2.0 (Ubuntu)
Triaged
Low
Unassigned

Bug Description

Steps to reproduce:
1. Click near the top left of a text field to focus it.
2. Start typing.
Or:
1. Click in a browser window to focus the page.
2. Read the page, scrolling with the arrow keys.
Or:
1. Click in an e-mail message window to focus the message.
2. Read the message, scrolling with the arrow keys.

What happens:
* The mouse pointer gets in the way of what you're typing/reading.

What should happen:
* Whenever you press a non-modifier key on the keyboard, if the pointing
device has been neither moved nor clicked in the past ~0.25 seconds, the pointer
should disappear until the pointing device is next moved or clicked.

But won't this make people lose the pointer?
* No. For human eyes, such a small object is much easier to find by movement
than by searching the entire screen. As soon as they grab the mouse again, the
pointer will appear, and they'll see where it is.

This is nuts!
* It's worked on the Mac for over two decades. Most people haven't noticed.
They just get slightly irritated on *other* platforms when the pointer gets in
the way.

(Apologies if this is filed under the wrong product.)

http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/PointerObscuring.html: http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/PointerObscuring.html

Revision history for this message
Daniel Stone (daniels) wrote :

I assume you mean that this behaviour doesn't occur under Firefox (it's not X's
responsibility, BTW); gnome-terminal and GTK apps in general do it.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

I hadn't noticed that it works for GTK single-line text fields. That's good. But
it doesn't work for other keyboard-controlled areas in Nautilus, Dictionary,
File Roller, Gnometris, Robots (when played using the keyboard), Gimp, gThumb,
xpdf, ggv (and Evince), Evolution (and Thunderbird), Gaim, GnomeMeeting, X-Chat,
Rhythmbox, Totem, gconf-editor, Network Tools, System Log Viewer, System
Monitor, CD Database Server, Desktop Background Preferences, File Management
Preferences, Keyboard Preferences, Keyboard Shortcuts, Network Proxy
Preferences, Screensaver Preferences, Sessions, Sound preferences, Theme
Preferences, Device Manager, Login Screen Setup, Network settings, Printers,
Synaptic, Users and Groups, and Yelp. So no, I don't think it's a bug in Firefox.

Even if the HIG said that applications should do it, and I went and reported
bugs on all those apps, some would still forget to implement it, or not bother
to do it, or do it incorrectly. And even if GTK did it for listboxes as well as
text fields, that would fix less than half the programs I listed above. Better
to implement it in a single place at a lower level, which is why I suggest it's
X's job.

Revision history for this message
Daniel Stone (daniels) wrote :

X is entirely about mechanism and not policy. This sort of thing is a job for
the toolkit/apps; reassigning to GTK.

Revision history for this message
Sebastien Bacher (seb128) wrote :

gtk does that for the text areas, works fine with gedit by example. You list a
bunch of applications without pointing what parts have an issue. Most of them
don't have a text entry, on which widget should the cursor by hidden too?

Revision history for this message
David Balažic (xerces8) wrote :

Amiga also had this feature.
Strange that there it was a few lines of code, while on linux it is an
unsurmontable problem.

Revision history for this message
Sebastien Bacher (seb128) wrote :

(In reply to comment #5)
> Amiga also had this feature.
> Strange that there it was a few lines of code, while on linux it is an
> unsurmontable problem.

Please read the previous comments and point your issues instead of making such
comments

Revision history for this message
David Balažic (xerces8) wrote :

The issue :
Mouse pointer should disappear, while I use the keyboard.
But in current version of Ubuntu, it does not.

Example apps : all, except a few...exceptions.
Examples: FireFox, CD player, Calculator ...

Changed in gtk+2.0:
status: Needs Info → Confirmed
Revision history for this message
David Balažic (xerces8) wrote :

The solution :
unclutter - hides the cursor in X after a period of inactivity

Changed in gtk:
status: Unconfirmed → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

The bug has been marked fixed upstream with that comment:

"GTK+ does this for entries and text views. I don't think it is really needed
anywhere else."

Marking the distribution task fixed, feel free to argue upstream if you want

Changed in gtk+2.0:
assignee: seb128 → desktop-bugs
status: Confirmed → Fix Released
Changed in gtk:
status: Fix Released → Unconfirmed
Revision history for this message
David Balažic (xerces8) wrote :

I just did some file browsing with the latest Feisty beta, using the keyboard.
Then, I had to reach for the mouse to move the pointer out of the way, becasue it was covering the name of the file...

Besides, this is not GNOME specific. Not all apps are GNOME/GTK+.

Revision history for this message
David Balažic (xerces8) wrote :
Revision history for this message
Gergely Máté (sportember) wrote :

HINT: It's a feature request, isn't it?

Revision history for this message
David Balažic (xerces8) wrote :

Why is this marked fixed ?
Nothing has been changed since the report.
And the upstream is not marked as fixed either.

Changed in gtk+2.0:
status: Fix Released → Triaged
Revision history for this message
David Balažic (xerces8) wrote :

Just noting it is same in Ubuntu 9.04...

Changed in hundredpapercuts:
milestone: none → round-10
status: New → Confirmed
Changed in hundredpapercuts:
milestone: round-10 → round-9
Revision history for this message
Vish (vish) wrote :

mpt wrote:
>But won't this make people lose the pointer?
> * No. For human eyes, such a small object is much easier to find by movement
> than by searching the entire screen. As soon as they grab the mouse again, the
> pointer will appear, and they'll see where it is.

Very interesting... I'v used gedit several times and i *never* noticed that the pointer was disappearing!
[why i write this comment is not to add a me too , but rather , when i looked at the title i was not happy with the pointer disappearing and wanted to comment against this! ;) on testing it it sounds very sane. ]

So now , how this is being done by gedit ? is this a xulrunner bug or a gtk only bug?

Revision history for this message
Tim Tilberg (ttilberg) wrote :

I just wanted to throw mine in:
It's certainly not something that bothers me to the point of aggression, however these types of things seem to be the point of the hundredpapercuts project anyway. Nothing terrible, just something that would make usability even more hassle free.
I especially would love this behavior added to Firefox.

Revision history for this message
Christian Berg (xeniac) wrote :

Hm... i never saw my cursor dissappearing, but now i look closly at my Cursor: Sometimes he dissapears, sometimes not.

In GTK:
Cursor dissapears if you type into a Textbox AND the cursor is over the Textbox
Cursor won't dissapear if you use type-away search in list (type the file you are looking for in nautilus for example)
Not so GTK native application behave randomly:
f-spot: no cursor hiding.
Chromium: Cursor hides in the "Awesomebar" but not in a HTML <textarea>

Conclusion
--------------
X is not respnisble to "enforce" such stuff
GTK Toolkit can't catch all cases of cursor hiding.
Users that are aware that the cursor hides, experience this as random.

What about the Windowmanager? If cursor is over the active window and there is keyboard-activity, then hide the cursor.
This would also catch wine-emulated stuff, and a whole lot of useful apps not with in GTK.

Changed in hundredpapercuts:
milestone: round-9 → lucid-round-3
Vish (vish)
Changed in hundredpapercuts:
importance: Undecided → Low
Revision history for this message
Luke Symes (allsymes) wrote :

I had a look at this today, scrolling through pages of gtk & gdk stuff. I have tried coding up a potential solution, and the preliminary patch is attached. Please note, it is just an experiment, and has not been tested in any way, it was just to see where I could solve the problem.

I think that it would be good for gtkwidget to have the main implementation which would then be inherited everywhere, but widgets need to be able to override it. Thus the patch needs more work so gtktextview and gtkentry can replace the gtkwidget implementation with their own.

Revision history for this message
David Balažic (xerces8) wrote :

IMO this should be done much "higher" than that (or lower, depends on the viewpoint).
What about all the non GTK/GDK apps?

But the patch is a good start.

tags: added: patch
Revision history for this message
Anonym25712 (anonym25712) wrote :

Why not rely on Unclutter to do this? I've been using it for months and it works flawlessly.

Changed in hundredpapercuts:
assignee: nobody → Dmitrijs Ledkovs (dmitrij.ledkov)
Revision history for this message
Nigel Babu (nigelbabu) wrote :

Luke, thank you for your patch. Can you submit the patch upstream as well?

tags: added: patch-needswork
removed: patch
Revision history for this message
Luke Symes (allsymes) wrote :

The patch is not in working order. It is just a rough idea, and perhaps I should remove it from here. Unclutter (from comment #20) seems like it would work for all programs, although I just installed it and it didn't make my cursor disappear when running "unclutter -keyword". The best thing to do would be to enhance Unclutter and then have it installed by default, and set to hide the cursor when just the keyboard is in use.

Revision history for this message
Nigel Babu (nigelbabu) wrote :

I'm unsubscribing reviewers for now. I'll talk to one of the devs about unclutter. Thank you for taking the time to submit a patch. If at a later time you decide to give it another go and want a review, feel free to subscribe ubuntu-reviewers

Changed in hundredpapercuts:
assignee: Dmitrijs Ledkovs (dmitrij.ledkov) → nobody
Vish (vish)
Changed in hundredpapercuts:
status: Confirmed → Triaged
Revision history for this message
Zev Goldstein (psywolf) wrote :

so for the time being, you can install unclutter and add "unclutter -keystroke" to your startup application to fix this problem. If you think this should be default behavior, or at least an option in the ubuntu mouse settings, then that isn't a papercut. Read the page on what a paper cut is and what a papercut isn't.

Revision history for this message
Vish (vish) wrote :

Maverick brings hope for mpt ;-) [ https://lists.launchpad.net/ayatana/msg02831.html ]

Changed in hundredpapercuts:
milestone: lucid-round-3 → maverick-round-4-potpourri
Vish (vish)
Changed in hundredpapercuts:
milestone: maverick-round-4-potpourri → maverick-round-7-notifications+gtk
Revision history for this message
Mark Shuttleworth (sabdfl) wrote :

Unclutter seems like the cleanest approach to solving this. I'll request that the desktop team consider it for MIR and the CD.

Changed in gtk+2.0 (Ubuntu):
importance: Wishlist → High
Revision history for this message
buratinas (buratinas) wrote :

I don't think that hiding a pointer when it does not disturb your vision is a good idea. For example now I am typing in this field and I find it's quite an advantage to see where the pointer actually is. At least hiding shouldn't be default behavior, people who really need this functionality will find it in the options.

Revision history for this message
David Balažic (xerces8) wrote :

Why is the mouse pointer so important while you type text?
Besides, it will appear the moment you touch the mouse.

Additional ideas, for v2.0 ;)
 - use a fade-in , fade-out effect instead of instant (dis/re)appearance
 - related to above comment: do not make pointer disappear completely, but fade it to 10% opacity ? Maybe depending on what is under the mouse, if it changes, make the pointer more transparent?
 - timeout for pointer hide: do not hide it right when the user starts typing, but after some time, like 1 or 2 seconds

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

I have just tested unclutter, and my recommendation is that it *not* be included in the default install or session. It does not solve the problem, and it introduces new problems.

Example 1: With unclutter running, click in an OpenOffice.org or AbiWord document, and start typing. The cursor should disappear instantly. It takes five seconds, by which time any benefit is lost, because you've typed out of range of the cursor anyway.

Example 2: Click in Firefox's search field and type a word or two. The cursor should disappear instantly, but it *never* disappears.

Example 3: Paint a brush stroke in Gimp, then pause for a few seconds considering your next stroke. The cursor disappears, and the status bar text changes distractingly. Neither should happen.

Revision history for this message
Sebastien Bacher (seb128) wrote :

being using it since yesterday I find the behaviour rather confusing as well, the change gives you the feeling that something has happened without clear indication of what and why, not having the cursor displayed after some second during mouse work or reading also slow next actions because you have first to move the mouse to know where the cursor is before doing something

Revision history for this message
David Balažic (xerces8) wrote :

Was that the timeout trigger?
I agree that it is "less intuitive".

Last time I tried unclutter, the trigger by keystroke did not work. That way is more intuitive and already used by some code (parts). Like the gnome terminal, and some (GTK+) text fields, IIRC.

Revision history for this message
frizzle21 (frederik-nnaji) wrote :

unclutter makes me feel better, since it remedies the main problem of visual obfuscation.
As little as the problem may be, it is gone, not perfectly, not consistently, not even natively patched, but as a user i already can say thanks.

i'd suggest to put some effort into WM-based solutions. No, this is not a feature request, no, toolkits, X or the respective single applications can not solve the problem by themselves, since its scale exceeds their respective areas.

Revision history for this message
neuromancer (neuromancer) wrote :

@Matthew Paul Thomas
I've also tried unclutter and for me it's a good compromise.
1) in open office cursor disappear nearly immediately (between 1 or 2 seconds) and this is very very comfortable when typing. If you move the mouse or change current application (with alt+tab switcher or something else) mouse cursor reappear.
2) in firefox cursor disappear both when reading something and when typing (in awesome bar or search bar)
3) in gimp I've your behavior but for me it's not distracting because mouse disappear only if you don't use it for a little gap of time (2 seconds I think)

In my opinion unclutter it's a good application that enhance the user experience.
One possibility would be to have an option on system>preferences>mouse to enable or disable the "unclutter behavior", so any user can eventually change it. (Default beahvior unclutter on > mouse disappear after a little gap of time [eventually configurable in this window too])

Revision history for this message
Grey Nicholson (greytheearthling) wrote :

mpt, sound like you're running unclutter without the -keystroke switch.

Revision history for this message
eyerouge (spam-eyerouge) wrote :

Matthew Paul Thomas:

To solve the GIMP-issue you experience you can use the -not switch, which could exclude GIMP from unclutters handling.

As for your two other examples you're right that there is no way to decide the timeout value within every specific program or in the detailed manner you wish (when in field x in program y then hide mouse after time z) by using unclutter.).

The two cases that you mention beside the GIMP one are _already_ a fact in Ubuntu: They are not the result of unclutter. While unclutter doesn't do the micro-management and is indeed a crude solution when put in your light nothing/very little seems to be worse off by inlcuding it in the OS if the options are a) should we have no solution or b) should we have a semi-solution?

What I'm personally afraid of is if nobody would work on a "real" (i.e. more advanced, in the lines of what you seem to request yourself) solution on this if indeed unclutter is included. Thus unclutter, a temporary fix, could end up giving much less incentive to create a real and more full solution of the problem(s) at hand.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

neuromancer, a "good compromise" between what? unclutter's behavior is worse than both the status quo and the behavior I specified.

Greg, thanks for the hint, but I just tested "unclutter -keystroke" and it seems to have no effect at all. (For example, the cursor does not hide when typing this bug comment.) Perhaps if someone fixed that as a separate bug, we could re-evaluate unclutter for inclusion.

eyerouge, I know that the first two cases are already a fact in Ubuntu; that's what I meant by "it does not solve the problem". I agree with you that including a purported solution to the problem might misdirect actual solutions (a similar thing has happened for two years with bug 161818, for example).

Revision history for this message
neuromancer (neuromancer) wrote :

@mpt
Good compromise between actual situation (mouse pointer always visible ) and solution proposed in this bug report (mouse pointer should disappear when typing, reading and all cases where mouse pointer is useless).

I'm using unclutter on lucid lynx from two weeks and I think that is very useful when writing (for example in this box but also in Open Office) and reading documents.
However I had meet some unpleasant behaviours, for example tooltip in firefox (alt and/or title of images, links etc.) or other browser disappear when mouse pointer disappear, if I try to listen a song from nautilus when mouse disappear song preview is restarted etc.

After that I think that unclutter is not mature for going in "production".

Probably mouse pointer should disappear quite immediately when *writing* and reappear after a little gap of time, when text cursor is probably distant.
Furthermore I think that there are situations where mouse pointer shouldn't disappear also if not in use (not on the go) and this complicate the unclutter behaviour.

Revision history for this message
Vish (vish) wrote :

Why are we trying to work around this with unclutter? why not fix this in gtk+ ?
gtk+ already does this for entries and text views.

Revision history for this message
Fabien Tassin (fta) wrote :

This is unusable here. After the last round of updates and a restart, when hovering a gtk app (like xchat or gwibber), the cursor starts to flicker like hell and the cpu sky rockets (Xorg, metacity and the given app).

Also, on non-gtk apps (like a regular xterm), the cursor completely disappears, which is bad for me as i'm using my w-m in follow focus mode. i.e. i *need* to see where the cursor is to see where i type.

for both these reasons, i have to kill (or uninstall) unclutter

my w-m setup:
===
gconftool-2 --set --type=bool /apps/metacity/general/compositing_manager true
gconftool-2 --set --type=bool /apps/metacity/general/auto_raise false
gconftool-2 --set --type=bool /apps/metacity/general/raise_on_click false
gconftool-2 --set --type=string /apps/metacity/general/focus_mode sloppy
gconftool-2 --set --type=string /apps/metacity/general/focus_new_windows smart
===

this with metacity and nvidia-current.

Revision history for this message
Martin Pitt (pitti) wrote :

I am on lucid, without unclutter, and in gedit, gnome-terminal etc. the mouse already disappears when I start typing. Shouldn't that be enough? It seems unclutter introduces quite a bunch of bugs (flickering, extra CPU usage, etc.)

Revision history for this message
Colin Watson (cjwatson) wrote :

Regarding comment 39, the workaround in bug 385034 helped me.

That said, the whole thing seems rather unpolished.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

Martin, see my 2005-05-09 comment. If it was enough, I wouldn't have reported the bug in the first place. :-)

Whoever added unclutter to the default seed, can they please remove it?

Revision history for this message
Martin Pitt (pitti) wrote :

Removed from seeds again.

papukaija (papukaija)
tags: added: maverick patch
Vish (vish)
tags: removed: maverick patch
Revision history for this message
Sebastien Bacher (seb128) wrote :

Changing to "low" that's a wishlist in theory, unclutter doesn't work well enough and that will not be changed this cycle now

Changed in gtk+2.0 (Ubuntu Maverick):
assignee: Ubuntu Desktop Bugs (desktop-bugs) → nobody
importance: High → Low
Revision history for this message
papukaija (papukaija) wrote :

Please don't remove the original patch tag.

tags: added: patch
Revision history for this message
Vish (vish) wrote :

@papukaija: Thanks for helping with Patch Review.
Kindly refer to <https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Workflow> and <https://wiki.ubuntu.com/ReviewersTeam/ReviewGuide#Examples> for a better understanding of the review workflow.

tags: removed: patch
Changed in gtk:
importance: Unknown → Wishlist
Vish (vish)
Changed in hundredpapercuts:
milestone: maverick-round-7-notifications+gtk → nt7-potpourri
Revision history for this message
David Balažic (xerces8) wrote :

Situation same in Ubuntu 11.04...

Revision history for this message
Marcus Haslam (marcus-haslam) wrote : Re: [Bug 16492] Re: Mouse pointer should disappear when keyboard is in use and mouse isn't

I'm out of the office until 1st August.

On 28 Apr 2011, at 22:09, David Balažic <email address hidden>
wrote:

> Situation same in Ubuntu 11.04...
>
> --
> You received this bug notification because you are a member of
> Papercutters, which is subscribed to One Hundred Paper Cuts.
> https://bugs.launchpad.net/bugs/16492
>
> Title:
>  Mouse pointer should disappear when keyboard is in use and mouse
> isn't
>
> Status in GTK+ GUI Toolkit:
>  New
> Status in One Hundred Paper Cuts:
>  Triaged
> Status in “gtk+2.0” package in Ubuntu:
>  Triaged
> Status in “gtk+2.0” source package in Maverick:
>  Triaged
>
> Bug description:
>  Steps to reproduce:
>  1.  Click near the top left of a text field to focus it.
>  2.  Start typing.
>  Or:
>  1.  Click in a browser window to focus the page.
>  2.  Read the page, scrolling with the arrow keys.
>  Or:
>  1.  Click in an e-mail message window to focus the message.
>  2.  Read the message, scrolling with the arrow keys.
>
>  What happens:
>  *   The mouse pointer gets in the way of what you're typing/reading.
>
>  What should happen:
>  *   Whenever you press a non-modifier key on the keyboard, if the
> pointing
>  device has been neither moved nor clicked in the past ~0.25
> seconds, the pointer
>  should disappear until the pointing device is next moved or clicked.
>
>  But won't this make people lose the pointer?
>  *   No. For human eyes, such a small object is much easier to find
> by movement
>  than by searching the entire screen. As soon as they grab the mouse
> again, the
>  pointer will appear, and they'll see where it is.
>
>  This is nuts!
>  *   It's worked on the Mac for over two decades. Most people
> haven't noticed.
>  They just get slightly irritated on *other* platforms when the
> pointer gets in
>  the way.
>
>  (Apologies if this is filed under the wrong product.)
>
>  http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/PointerObscuring.html
> :
>  http://www.quinn.echidna.id.au/Quinn/WWW/HISubtleties/PointerObscuring.html

Revision history for this message
Marja Erwin (marja-e) wrote :

I disagree. I often have trouble with the cursor disappearing - not right now, but other times - when I'm typing in Firefox. I also had trouble with the cursor jumping about because of the malfunctioning Alps touchpad. So the cursor would jump and change the insertion point for new text, etc. and I couldn't even see it!

Please, try to make sure the cursors ARE visible.

Revision history for this message
David Balažic (xerces8) wrote :

It seems you are talking about the text cursor, while this bug is about the mouse pointer (also called "cursor").

Revision history for this message
Sascha (skbierm-deactivatedaccount) wrote :

Solution:

The feature of the hiding cursor could is there, you only have to install the software unclutter and start it with every start of you're Unity via startprograms.

Installation: sudo apt-get install unclutter

I added a video to my comment, showing that unclutter hides the mouse cursor, the moment the first key is pressed. It works with any DE or WM using X.

Changed in hundredpapercuts:
milestone: nt7-potpourri → quantal-11-misc
milestone: quantal-11-misc → quantal-10-gtk
Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

Can anyone please confirm if this is still an issue in 12.10, and if so, does anyone know how easy it will be to fix?

Changed in hundredpapercuts:
milestone: quantal-10-gtk → raring-misc
importance: Low → Wishlist
assignee: nobody → Papercuts Ninja (papercuts-ninja)
Revision history for this message
Dario Ruellan (druellan) wrote :

Ubuntu 12.10

Gedit, Ubuntu Software Center (GTK3): the mouse pointer gets hidden when I start typing.
Firefox, OpenOffice (GTK2): the mouse pointer remains on screen when I start typing, even if the cursor is right above the typed text.

Seems that currently its a GTK2 problem only. Firefox is working to bring a GTK3 version. Don't know about OpenOffice or other core GTK2 apps. Perhaps worth fixing.

Revision history for this message
David Balažic (xerces8) wrote :

Actually, GTK3 is the only library having it fixed.
Also some GTK2 apps might have had it fixed (cursor over text input
box and similar).
(almost) Everything else (like non GTK apps) still has this problem.

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

I'm going to close the paper cut task on this one. GTK3 is the application toolkit shipped by default with Ubuntu, so problems with GTK2 are outwith the scope of our project.

Changed in hundredpapercuts:
status: Triaged → Invalid
importance: Wishlist → Undecided
assignee: Papercuts Ninja (papercuts-ninja) → nobody
milestone: raring-misc → none
Revision history for this message
David Balažic (xerces8) wrote :

From https://wiki.ubuntu.com/PaperCut:

"A paper cut is a trivially fixable usability bug that the average user would encounter in default installation of Ubuntu or Kubuntu Desktop Edition."

Firefox is part of the default installation.

On the other hand, this fails on the "trivially fixable" part.

PS: The https://wiki.ubuntu.com/PaperCut page is missing in action. (it shows "This page does not exist yet. You can create a new empty page, or use one of the page templates.")

Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

On 7 November 2012 10:51, David Balažic <email address hidden> wrote:

> >From https://wiki.ubuntu.com/PaperCut:
>
> "A paper cut is a trivially fixable usability bug that the average user
> would encounter in default installation of Ubuntu or Kubuntu Desktop
> Edition."
>

I know, and I considered that. In the end, there's only so much time and
resources that can be devoted to paper cuts by the contributors, and when
there is already an effort to port Firefox to GTK3 (
https://bugzilla.mozilla.org/show_bug.cgi?id=627699), I don't think's it's
a good idea to carry out any work that will only be applying a sticking
plaster to an issue that'll be resolved in due course.

PS: The https://wiki.ubuntu.com/PaperCut page is missing in action. (it
> shows "This page does not exist yet. You can create a new empty page, or
> use one of the page templates.")

Woops, my bad. I was consolidating the paper cut pages and seem to have
missed that one. It now forwards to OneHundredPaperCuts, which is where I
simply moved all of its content.

Revision history for this message
David Gomes (davidgomes) wrote :

I really dislike it when my mouse disappears, I like to know where it is if I have to pick it up while writing. For example, while writing this comment I could have the need to check my email or IRC. I do feel it'd be great as an option though.

Cody Garver (codygarver)
no longer affects: elementaryos
Revision history for this message
Chris Wilson (notgary-deactivatedaccount) wrote :

Reopening paper cut task as part of a review of closed paper cuts.

Changed in hundredpapercuts:
status: Invalid → New
no longer affects: gtk+2.0 (Ubuntu Maverick)
James Ramsay (f-jack)
Changed in hundredpapercuts:
status: New → Triaged
status: Triaged → New
Revision history for this message
Adam Smith (adam-disc0tech) wrote :

Still exists in latest trusty. Tested in Firefox.

Changed in hundredpapercuts:
status: New → Confirmed
papukaija (papukaija)
tags: added: trusty
Changed in hundredpapercuts:
importance: Undecided → Low
status: Confirmed → Triaged
Revision history for this message
A. Eibach (andi3) wrote :

No 'unclutter' here on Lubuntu Utopic (beta; default). Had to install it manually. Considering the age of this "bug", and that even Mr. Ubuntu himself has replied here, this should have been included in the default distro long ago??

Anyways, this is not why I chose to comment here as well.

A good idea would maybe also be a CLIENT-SERVER solution. (or client-daemon if you insist)

Compare: With only basic Python knowledge, you can write a scriptlet that might catch messages sent via dbus using something like notify-send.
This might be a way out for this mouse pointer hide/show issue as well.
 The daemon/server would be used as an observer to keep on guard for idle keyboard and whatnot, and if so, send an internal message to the various clients (e. g. text-processing apps) that can hide the cursor.

Downer/Disadvantage:

EACH of these applications will have to be made "message-aware" first before the observer can send its demand to them.

Revision history for this message
Matthew Paul Thomas (mpt) wrote :

A. Eibach, has unclutter improved at all on the reasons it was removed from the default install before (described in my 2010-06-17 comment)?

I suspect that an external utility will always be too slow, Ubuntu has so many toolkits that trying to fix it there will always be a game of whack-a-mole, and X maintainers will balk at anything that smells like "policy". So it may be that the only reliable way to fix this is in Mir or Wayland.

Changed in gtk:
status: New → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.