<Company> should workaround this problem in menuitems - of course, similar workarounds are needed elsewhere :/
<Company> what this does is it explicitly defines a color for all widgets in menuitems
instead of just making them copy from their parent
so whenever the parent is not the menuitem and defines a color, this will override it
i'm not aware of anyone putting any intermediate widgets into menuitems, so I don't think there will be side effects
hrm, cases where the menuitem changed the color would also be effected
like the different menuitem style in unity 10 lines down
comboboxes have that workaround already it seems
so i guess yes, there might be side effects"
...
"you'll potentially see that problem everywhere where someone changes a menuitem from insensitive back to sensitive and does not recreate the menu, but just hides it"
suggested workaround:
"--- cvs/light- themes/ Ambiance/ gtk-3.0/ gtk-widgets. css~ 2012-04-07 18:36:48.832073000 +0200 themes/ Ambiance/ gtk-3.0/ gtk-widgets. css 2012-04-19 19:05:43.158282563 +0200
+++ cvs/light-
@@ -1126,7 +1126,8 @@
/************
* menuitem *
************/
-.menuitem {
+.menuitem,
+.menuitem * {
color: @fg_color;
}"
<Company> should workaround this problem in menuitems - of course, similar workarounds are needed elsewhere :/
<Company> what this does is it explicitly defines a color for all widgets in menuitems
instead of just making them copy from their parent
so whenever the parent is not the menuitem and defines a color, this will override it
i'm not aware of anyone putting any intermediate widgets into menuitems, so I don't think there will be side effects
hrm, cases where the menuitem changed the color would also be effected
like the different menuitem style in unity 10 lines down
comboboxes have that workaround already it seems
so i guess yes, there might be side effects"
...
"you'll potentially see that problem everywhere where someone changes a menuitem from insensitive back to sensitive and does not recreate the menu, but just hides it"