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 584846 - Eject/Unmount icon in Nautilus sidebar should have hover and click states
Eject/Unmount icon in Nautilus sidebar should have hover and click states
Status: RESOLVED DUPLICATE of bug 544103
Product: nautilus
Classification: Core
Component: Sidebar
2.26.x
Other All
: Normal minor
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-06-04 17:14 UTC by Andrew Starr-Bochicchio
Modified: 2010-04-30 08:28 UTC
See Also:
GNOME target: ---
GNOME version: 2.27/2.28


Description Andrew Starr-Bochicchio 2009-06-04 17:14:25 UTC 
Forwarded from Launchpad:
https://bugs.edge.launchpad.net/+bug/383255

"Lack of hover state for this icon makes it feel non-clickable. Click action does not feel right either, as you don't see any immediate feedback (e.g. color or bg change).

I'd suggest making the icon glow on hover (similar to folder icon behaviour) and go darker on click."

Other information:
Comment 1 Milan Bouchet-Valat 2009-06-20 09:49:06 UTC 
I've tried to implement this some time ago, and the prelight-on-hover part is really tricky to get with the current design of GtkTreeView. We already have an option to highlight a renderer when the mouse pointer enters the row, but the tree view has no real concept of an independent button that would be a renderer (a cell, as opposed to a whole row).

Signals about the pointer entering an area only get transmitted by the tree view on a row basis. Thus, you cannot know from the renderer POV when the mouse has entered your cell, only when it has entered your row. Clicks are transmitted to cell renderers because some computation of coordinates takes place when such an event occurs; this behavior should be replicated every time the pointer moves.

To sum up, this bug is not a mere paper-cut - you have to play with the terrible code of the GtkTreeView, where some functions are very very long... ;-)
I'll try to see if I can find ideas to solve this, if somebody wants to tackle that.
Comment 2 Milan Bouchet-Valat 2009-06-20 10:38:27 UTC 
See bug 586458 for the GtkTreeView part, where most of the work must take place.
Comment 3 Ryan 2009-06-24 02:02:03 UTC 
While we're at it, we should probably add a throbber or something to indicate that the system is currently working on ejecting it.
Comment 4 Cosimo Cecchi 2010-04-30 08:28:19 UTC 
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.

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