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 101546 - Wrong focus colour used for launchers
Wrong focus colour used for launchers
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: panel
2.1.x
Other All
: Normal major
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks:
 
 
Reported: 2002-12-18 19:01 UTC by Calum Benson
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
HighContrastInverse gtkrc file (8.56 KB, text/plain)
2002-12-20 16:21 UTC, Calum Benson
  Details
Proposed patch (2.04 KB, patch)
2002-12-23 12:56 UTC, padraig.obriain
none Details | Review

Description Calum Benson 2002-12-18 19:01:43 UTC
In recent days I've noticed the focus indicator drawn around launchers on
the panel isn't the one specified in the gtkrc file.  The correct colour is
used for drawers, menus and applets, though.  This also seems to be present
in recent Sun FCS builds :/
Comment 1 Mark McLoughlin 2002-12-18 19:05:55 UTC
Calum, could you attach a gtkrc that makes the problem clear (don't
forget I'm colour blind - it'll need to be *really* clear :-)

Comment 2 padraig.obriain 2002-12-19 10:55:04 UTC
I do not see this on my system which is running fcs-07.

When using Inverse theme the focus dotted line around launchers in the
panel are visible for me.
Comment 3 Calum Benson 2002-12-20 16:20:16 UTC
Mark, the inverse themes in gnome-themes show this up clearest for me,
rc file attached.  The focus line is white around applets etc., but
around launchers it seems to become grey, which is pretty much
invisible.

As Padraig says, it doesn't seem to happen on his Solaris box, but I
see it both on mine (fcs-07) and on my linux build from head (a couple
of weeks old) :/
Comment 4 Calum Benson 2002-12-20 16:21:33 UTC
Created attachment 13133 [details]
HighContrastInverse gtkrc file
Comment 5 Mark McLoughlin 2002-12-22 23:52:28 UTC
(Calum, you should re-open a NEEDINFO bug when you add info)

Calum: hmmmm. You see the problem here is that the button is put into
the PRELIGHT state. That happens when you mouse-over the button -
which is fair enough, that's what happens all buttons - but then
doesn't seem to go away again. If you need this fixed now then you
might want to consider adding something like this to the themes:

style "panel-button"
{
  fg[PRELIGHT] = { 0.00, 0.00, 0.00 }
}
class "ButtonWidget" style "panel-button"


Padraig: if you are debugging this, the "in_button" GtkButton flag is
what puts the button into that state. See gtk_button_update_state.

So. There's a few things here that I'm curious about but don't have
time to look into.

1) We never want a ButtonWidget in PRELIGHT really, but maybe that's
wrong. It is a button so it should go into PRELIGHT, so maybe for the
panel's ButtonWidget we just want to make PRELIGHT the same as NORMAL.
Or maybe we just want to always use the NORMAL state when painting
focus. Thoughts?

2) There must be a bug in ButtonWidget that once it goes into PRELIGHT
it doesn't get out of it again.

3) I hate ButtonWidget

hmmm
Comment 6 padraig.obriain 2002-12-23 12:54:06 UTC
I was able to reprdouce the problem after I moved the mouse unto the
button.

The problem is, as Mark, suggests, that the button's state remains
PRELIGHT. I have a patch to fix that problem, which I believe fixes
this bug.
Comment 7 padraig.obriain 2002-12-23 12:56:22 UTC
Created attachment 13183 [details] [review]
Proposed patch
Comment 8 Vincent Untz 2002-12-30 13:37:21 UTC
adding PATCH keyword.
Comment 9 Mark McLoughlin 2003-01-01 20:31:12 UTC
Looks good Padraig. Please commit ... and thanks.
Comment 10 padraig.obriain 2003-01-02 16:30:25 UTC
Patch committed to HEAD.