GNOME Bugzilla – Bug 645751
Activities prelight changes as hot corner is activated
Last modified: 2011-03-28 20:17:38 UTC
Originally reported by William Jon McCann, lost in the outage As you move across the Activities item in the top bar it prelights (color=white) but as you continue to move to the corner the text changes to the normal text color.
Created attachment 184290 [details] [review] Panel: sync primary hotcorner hover with Activities button Since the hotcorner is a reactive actor, and it is over the Activities button, hovering on it results in a leave-event for the button. This is not noticeable when opening the overview, as the button is correctly prelighted, but it is when closing, if you keep the mouse near the hot corner, as the button is kept in normal state, despite the mouse being over it.
Review of attachment 184290 [details] [review]: Not quite right - this ends up with the hover state not set for the 3x3 pixel "environs" (this.actor), so you still have flashing as you enter and leave the corner.
I had said before on the original bug, a better fix would be to make the hotspot be a child of the button. Then the "hover" flag would propagate automatically.
(In reply to comment #3) > I had said before on the original bug, a better fix would be to make the > hotspot be a child of the button. Then the "hover" flag would propagate > automatically. That won't work, because the panel has padding, and the corner would not be allocated at the corner (unless using another anchor-point hack, that I would prefer to avoid).
Created attachment 184363 [details] [review] Panel: sync primary hotcorner hover with Activities button Since the hotcorner is a reactive actor, and it is over the Activities button, hovering on it results in a leave-event for the button. This is not noticeable when opening the overview, as the button is correctly prelighted, but it is when closing, if you keep the mouse near the hot corner, as the button is kept in normal state, despite the mouse being over it.
(In reply to comment #4) > (In reply to comment #3) > > I had said before on the original bug, a better fix would be to make the > > hotspot be a child of the button. Then the "hover" flag would propagate > > automatically. > > That won't work, because the panel has padding, and the corner would not be > allocated at the corner (unless using another anchor-point hack, that I would > prefer to avoid). The button seems to extend both to the top of the screen and the side of the screen.
(In reply to comment #6) > The button seems to extend both to the top of the screen and the side of the > screen. Yes, and very much intentional (Fitts bla bla) - of course, themes are free to break it, but that's more an argument against user themes than doing the right thing here ...
(In reply to comment #6) > (In reply to comment #4) > > (In reply to comment #3) > > > I had said before on the original bug, a better fix would be to make the > > > hotspot be a child of the button. Then the "hover" flag would propagate > > > automatically. > > > > That won't work, because the panel has padding, and the corner would not be > > allocated at the corner (unless using another anchor-point hack, that I would > > prefer to avoid). > > The button seems to extend both to the top of the screen and the side of the > screen. Padding is inside, not outside. See st_theme_node_get_content_box(), which here returns { x1: 12, x2: 63, y1: 0, y2: 26 }.
Review of attachment 184363 [details] [review]: Looks good,has release team approval, http://mail.gnome.org/archives/release-team/2011-March/msg00476.html
Attachment 184363 [details] pushed as 9f438d0 - Panel: sync primary hotcorner hover with Activities button