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 668141 - button: don't be active when holding the mouse button outside the bounds
button: don't be active when holding the mouse button outside the bounds
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
unspecified
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2012-01-17 22:19 UTC by Cosimo Cecchi
Modified: 2012-03-01 20:58 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
button: don't be active when holding the mouse button outside the bounds (1.10 KB, patch)
2012-01-17 22:19 UTC, Cosimo Cecchi
committed Details | Review

Description Cosimo Cecchi 2012-01-17 22:19:00 UTC
See commit for the rationale
Comment 1 Cosimo Cecchi 2012-01-17 22:19:03 UTC
Created attachment 205486 [details] [review]
button: don't be active when holding the mouse button outside the bounds

GtkButton currently draws itself as active (pressed down) in case we're
pressing and holding the mouse pointer outside its bounds; this is
misleading though, since we won't activate the button unless the mouse
is released inside the button itself.
Fix this by only setting the ACTIVE state flag when the button is
actually pressed down.
Comment 2 Matthias Clasen 2012-01-17 22:31:54 UTC
Not convinced this is the right thing to do, as expressed on irc:

<cosimoc> mclasen, patch for one of the things mccann was reporting today: https://bugzilla.gnome.org/show_bug.cgi?id=668141
<cosimoc> mclasen, I yet have to test it some more, not sure it doesn't break anything else
<mclasen> dunno, to me, the keep-it-depressed-until-I-let-go is pretty deeply ingrained
<mclasen> I am always irritated by buttons that do it wong and snap back as soon as I move out
<mclasen> it kinda goes with the implicit grab
<mclasen> I would expect the button to snap back when the grab is broken
<cosimoc> mclasen, what
<cosimoc> ops
<cosimoc> mclasen, what's the point of keeping it depressed if it won't activate? it's misleading
<cosimoc> the button already snaps back when the grab is broken (at least, I see code that does that)
<mclasen> as I said, for me, the depressed visual is mentally connected to the grab
<cosimoc> not everybody knows what a grab is though :)
<mclasen> if I see the button snap back before I lift my finger, I have the impetus to check if my mouse button is broken
<cosimoc> even if the pointer is not on the button?
<mclasen> yeah
<mclasen> its different from hover
<mclasen> which you very much expect to go away if you move the pointer off
<mclasen> but then, maybe I'm just a grumpy old mouse user
<cosimoc> don't know...other platforms (e.g. osx) don't seem to keep it pressed
<cosimoc> not sure about windows
Comment 3 Cosimo Cecchi 2012-03-01 20:58:23 UTC
Attachment 205486 [details] pushed as 5495152 - button: don't be active when holding the mouse button outside the bounds