Bug 498422 - theme/engine doesn't set foreground colour
theme/engine doesn't set foreground colour
Product: Fedora
Classification: Fedora
Component: notification-daemon-engine-nodoka (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Martin Sourada
Fedora Extras Quality Assurance
: 506579 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2009-04-30 08:39 EDT by cje
Modified: 2009-11-08 23:37 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-11-08 23:37:50 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
pretty notification with visible text and buttons. (14.45 KB, image/png)
2009-08-17 11:15 EDT, cje
no flags Details

  None (edit)
Description cje 2009-04-30 08:39:26 EDT
Description of problem:
the nodoka notifications are lovely but because i'm using a dark desktop theme (darklooks) i get white text on a light yellow background - so i can't read the messages.

Version-Release number of selected component (if applicable):
Comment 1 Martin Sourada 2009-05-20 05:17:23 EDT
Erm, sorry about the late reply, I'm kinda busy lately. I can reproduce the issue and will look into it as soon as I have enough time.
Comment 2 Martin Sourada 2009-05-20 05:25:28 EDT
Actually, thinking about the best solution, do you think having background respect colour settings from your gtkrc (instead of the hardcoded yellow colour which is the case now) or hardcoding the text colour to black would be a better approach? I am leaning towards the former, although the later would be easier to implement.
Comment 3 cje 2009-05-20 08:40:53 EDT
no problem.  :-)

i'm not sure about how gtkrc works but from the point of view of the 'Customise Theme' dialog from 'Appearance Preferences' there's a pair of colours for tooltips which you could hook into.

personally, until "they" add 'Notifications' to that list of colours or there's an official declaration of which of the existing colours should be used for notifications (e.g. 'tooltips' or 'windows') i'd make it hardcoded.

the most important thing is to make it consistent between the foreground and background - either hardcode both or hardcode neither.
Comment 4 Leszek Matok 2009-05-20 12:03:45 EDT
I have the same problem as reporter since upgrading to F11. Previous notifications did actually respect my Darklooks theme and this is the way I want it.

You know, it really looks ugly, even if you make the text forcibly black. This will solve one problem (text being almost invisible), but a second one stays: in my dark-to-black elegant desktop this popup window looks like a drag queen on a funeral :)

If someone was trying to make it similar to tooltips, he forgot to use their colors. Making the gradient dependent on the tooltip color is very good idea + make the text dependent on their text color as well.

Why the default tooltip color pair for Darklooks is still black-on-bright-yellow is another matter, if you know of a bug number for that, you can share, I'll add my proposal :)
Comment 5 Bug Zapper 2009-06-09 10:52:57 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
Comment 6 Martin Sourada 2009-06-18 04:17:23 EDT
*** Bug 506579 has been marked as a duplicate of this bug. ***
Comment 7 Martin Sourada 2009-06-20 04:15:43 EDT
Can you try?

It's built for Rawhide, but should probably work on previous F10 or F11 as well. It uses gtkrc specified colour as background, alas for all themes I've tried this is the same to the color that this used on windows background and I still don't know what exactly could change the color via gtkrc...
Comment 8 Leszek Matok 2009-06-28 09:10:03 EDT
This is MUCH better!

However, the "X" button (to dismiss the notification) is invisible:
It is there and can be found hovering the mouse pointer over it:

The cause is probably using default "X" color used by tabs, where at the same time not using the same background color as tabs. Take a look at this screenshot:

From top to bottom:
- X to close inactive gnome-terminal (light grey on dark grey)
- X to close a tab in gnome-terminal (black on dark grey)
- X to close another inactive window
- X to close another inactive window, toolbox-style
- X to close an active window (more contrast than inactive - solid white on darker grey)
- X to close a tab in Pidgin (surprise: light grey on dark grey)

For a flat "X" button, Pidgin uses text "x" and text color (I think this saves space comparing to normal GTK+ tabs).

I think the proper thing to do for notifications is:
- change background to be the same as "widget background", not "text background" (menu bars, tabs, status bars, buttons all have the "widget background I'm talking about; text areas, one-line inputs, lists all use the almost-black "text background" which current notifications seem to use), or
- to use text color/button label color for the X, just what Pidgin does and consistent with action buttons.

On my desktop, I think first option would look better, because now the notifications' borders are almost invisible and the window blends into the desktop, apart from the urgency color on the left. I don't know how this change may effect other themes, though.
Comment 9 cje 2009-08-17 11:15:30 EDT
Created attachment 357664 [details]
pretty notification with visible text and buttons.

sorry i've taken so long to try this.

huge thanks for the update - it's fantastic.  my colleagues are very envious (the google-droid fonts and gartoon icons help a bit though)!

for what it's worth, i suspect the "X" problems Leszek has reported might be caused by the kerneloops app itself, not the theme.  my impression is that the kerneloops notifications always look a bit odd.  all my other notifications look fine.  (see attached image.)

can this change get a release now?  it's a vast improvement regardless of whether it needs further refinement.

Note You need to log in before you can comment on or make changes to this bug.