GNOME Bugzilla – Bug 109213
GtkNotebook buttons in labels get highlighted on tab switch
Last modified: 2011-02-04 16:17:01 UTC
Open Galeon. Open a second tab. Switch from one tab to another (either via mouse or Ctrl-PgUp/PgDown) The close button in the inactive labels will be highlighted. The highlighting will disappear when moving the mouse over the button and away again. I'm posting this here and not on Galeon because I believe this bug only appeared after updating from 2.2 to 2.2.1, though I'm not sure about this. I'll attach a screenshot showing the bahaviour.
Created attachment 15205 [details] a bug :)
*** Bug 112963 has been marked as a duplicate of this bug. ***
*** Bug 112722 has been marked as a duplicate of this bug. ***
The problem here is the change from bug 93389 which propagates state to child widgets. We probably need some way for GtkButton to avoid picking up the state from it's parent.
*** Bug 114700 has been marked as a duplicate of this bug. ***
Created attachment 18602 [details] Python example of workaround for this problem
We want to add a widget flag "does not inherit state". Because this adds API, this has to be done in private for the 2.2 series. Though, we feel that it's better to do this correctly at once, in public, in the 2.4 series. Punting to 2.4 API Freeze.
*** Bug 120802 has been marked as a duplicate of this bug. ***
I made a patch which fixes this problem. It doesn't break the API or ABI (afaik), and fixes the issue for all cases in 2.2. I'm sure this patch would be easily ported to HEAD as well.
Created attachment 21424 [details] [review] Patch to fix the bug with buttons in notebook tab labels
This patch makes sense to me. An active, RELIEF_NONE button that isn't depressed should probably not have a bevel drawn. The test in the patch is logically equivalent to if (relief != none || (active && depressed) || prelighted || selected) paint_box(); which makes me wonder if it shouldn't simply be if (relief != none || depressed || prelighted) paint_box ();
Created attachment 21429 [details] [review] Revised patch to fix buttons in GtkNotebook tab labels
Attached new patch that changes the logic to ssp's suggested conditional.
Can I commit this patch?
*** Bug 131204 has been marked as a duplicate of this bug. ***
Moving to 2.4.0 as the proposed fix doesn't involve API changes.
The patch looks fine (I seem to remember that button->depressed is a GTK+-2.0 era addition, which is probably why it isn't used currently.) It's not really a complete solution to the problem (try entering and leaving a non-active tab) but without fixing bug 93389 it's probably about as good as you can do. After applying this patch, I'd mark this as depending on bug 93389 and move it to a later milestone.
I guess you mean bug 98207, as the one you mentioned is already fixed.
For reference, the patch was applied to 2.3.x on 2003-02-13. Should I leave the bug open?
It would be nice if I could commit the patch to the 2.2 branch also, since it doesn't break API, and fixes a rather annoying bug that was introduced in the 2.2 cycle by a fix for another bug in GtkContainer (I believe). I don't know why the target milestone got set to 2.6 api freeze though, since it has apparently been accepted into 2.3.
No new backports to 2.2.x are being done currently. The chance that we'll get to a 2.2.5 before 2.4.0 next Monday is minimal. Fri Feb 13 01:31:44 2004 Matthias Clasen <maclas@gmx.de> * gtk/gtkbutton.c (_gtk_button_paint): Don't draw bevels around active, RELIEF_NONE buttons that aren't depressed. This improves the appearance of buttons in notebook tabs. (#109213, reported by Benjamin Otte, patch by Rodney Dawes) I think the reason that this is kept open maybe the dependency on bug 98207 for a real fix, but probably simpler to just close this and do a comprehensive review when we fix 98207.
I don't know if I would call it a "new backport" since the patch was made against 2.2 and only applied to 2.3. I've been using the patch with 2.2, on several systems, since 2003-11-13 when I created the original patch. Whether or not a 2.2.5 comes out by 2.4 seems irrelevant to whether or not the patch should at least go into the branch.