Checkboxes and radiobuttons almost invisible using Human themes

Bug #553393 reported by Ricardo Pérez López on 2010-04-01
88
This bug affects 16 people
Affects Status Importance Assigned to Milestone
community-themes
Low
Unassigned
human-theme
Low
Unassigned
human-theme (Ubuntu)
Low
Unassigned

Bug Description

Binary package hint: human-theme

Using Human theme (or some of its derivatives) in Lucid, the check boxes and the radio buttons are almost invisible because they're displayed with a white color (which is practically the same color as the background).

Affected themes: Human, Homosapien, Sorbet, and possibly others.

I attach an screenshot to illustrate the problem: in it, a window's drop-down menu it's displayed, selecting "Siempre encima" (with a "check" mark) and "Sólo en este área de trabajo" (with a radio button).

Moreover, the white foreground color for checkboxes and radiobuttons conflicts with the black color used by the other icons in the menu: minimize, maximize and close (all perfectly visible).

Ricardo Pérez López (ricardo) wrote :
Ricardo Pérez López (ricardo) wrote :

Now using Homosapiens theme, displaying the indicator-session's drop-down menu. Can you tell me which option is selected? (SPOILER: it's "Ausente").

This issue has been introduced a few days ago. Before that, the radiobuttons and checkboxes were displayed correctly using black color.

Changed in community-themes:
status: New → Confirmed
Changed in human-theme:
status: New → Confirmed
Changed in human-theme (Ubuntu):
status: New → Confirmed

Noticed this issue too, hope it gets fixed soon, as the final release is just around the corner.

Vish (vish) wrote :

Those are new widget_classes and the themes need to use the following:

style "radiocheck-new"
{
 text[NORMAL] = blah
 text[PRELIGHT] = blah
 text[ACTIVE] = blah
 text[SELECTED] = blah
 text[INSENSITIVE] = blah
}

widget_class "*<GtkCheckMenuItem>*" style "radiocheck-new"
widget_class "*<GtkRadioMenuItem>*" style "radiocheck-new"

Text normal and prelight are essential not sure where the others are used , so the respective theme authors need to check that ;-)

Changed in human-theme (Ubuntu):
importance: Undecided → Low
status: Confirmed → Triaged
Changed in human-theme:
importance: Undecided → Low
status: Confirmed → Triaged
Changed in community-themes:
importance: Undecided → Low
status: Confirmed → Triaged
redacted (redacted) wrote :

If you look into the gtkrc files for the human-theme themes, you'll find this section:
style "murrine-radiocheck"
{
    text[NORMAL] = @selected_fg_color
    text[PRELIGHT] = @selected_fg_color
    bg[SELECTED] = @selected_bg_color # HACK: override button selection colour
}

At first, I though I solved the problem by commenting out the text[NORMAL] line.
#text[NORMAL] = @selected_fg_color

This did solve the menu drop-down issue. However, I soon discovered it created an issue with regular radio buttons and check boxes. They were now black instead of white by default. The black against the dark brown color that is the default for human-themes caused the check/dot to barely be visible.

Next, I commented out the bg[SELECTED] line.
#bg[SELECTED] = @selected_bg_color # HACK: override button selection colour

This lightened the brown color in the background of checked check boxes and radio dots to a usable state. It works, but it's hardly ideal.

Ideally, I'd expect checks/dots in drop-down menus to be black by default and white when moused over. I'd expect regular check boxes and radio dots to be white normally and black when moused over.

Alistair Buxton (a-j-buxton) wrote :

The way this is implemented in human theme is really confusing. The same class is used for Button and MenuItem widgets. This doesn't work because MenuItems are rendered without a background. It is possible to style them with different classes, then you can do whatever you want.

I attach a patch to the human-theme gtkrc file which makes the MenuItems use fg_color and selected_fg_color when the mouse is over them. This means the tick marks are always the same colour as the text. The Button type widgets are unaffected by this patch.

Max Bowsher (maxb) on 2010-06-09
tags: added: regression-release
Mikael Magnusson (mikma) wrote :

Patch in #6 seems to work. Attaching it in unified context format.

Max Bowsher (maxb) wrote :

The fix here is definitely an improvement. Can we get this SRUed?

buratinas (buratinas) wrote :

Can this be included at least to the upstream? This fix should definitely be merged to Maverick.

Vish (vish) wrote :

Fix for this bug has been committed in upstream branch lp:human-theme .

@Andrew Starr-Bochicchio, can we get a maverick update for this bug?

Changed in human-theme:
status: Triaged → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package human-theme - 0.39.1

---------------
human-theme (0.39.1) maverick; urgency=low

  * Fix visibility of RadioChecks to work better with latest murrine (LP: #553393)
 -- K Vishnoo Charan Reddy <email address hidden> Sun, 05 Sep 2010 00:55:57 +0530

Changed in human-theme (Ubuntu):
status: Triaged → Fix Released
Vish (vish) wrote :

@ Ori Avtalion [salty-horse] , finally got this fix uploaded . enjoy.. ;-)

Changed in human-theme:
status: Fix Committed → Fix Released
Ori Avtalion (salty-horse) wrote :

Vish, The change made the "regular" check boxes and radio buttons also black.
I was expecting you to apply Alistair Buxton's patch, but this is also fine :)

Vish (vish) wrote :

@Ori Avtalion , the black checkmark is intended, because with latest Maverick murrine checkmarks extend out of the box
If you are using it in earlier versions too, it will work.. but not as intended for Maverick murrine.

Attaching screenshot of how it appears with Maverick murrine.

Ori Avtalion (salty-horse) wrote :

Makes sense :) Thanks for the clarification

L3ttuce (ifearx) wrote :

Try as I might with Murrine 0.98.1.1, I cannot seem to get a background behind the radios and checks inside of menus, using Maverick, or is that not the case anymore with the engine?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers