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 160944 - the text font color on transparents panel should depend of the background
the text font color on transparents panel should depend of the background
Status: RESOLVED OBSOLETE
Product: gnome-panel
Classification: Other
Component: general
2.12.x
Other Linux
: Normal normal
: ---
Assigned To: Sven Herzberg
Panel Maintainers
: 86952 162291 166597 169335 169624 302276 314916 340597 346504 430155 481664 (view as bug list)
Depends on: 340015
Blocks:
 
 
Reported: 2004-12-10 12:08 UTC by Sebastien Bacher
Modified: 2016-12-02 14:59 UTC
See Also:
GNOME target: ---
GNOME version: 2.15/2.16



Description Sebastien Bacher 2004-12-10 12:08:35 UTC
nautilus acts in this way, it changes the font color in function of the
background color so you still have a clear difference between both and the text
is reasy to read.
Comment 1 Vincent Noel 2004-12-10 19:05:47 UTC
I think this will need to be implemented in each applet :-(
this is related to bug 86952
Comment 2 Vincent Untz 2004-12-23 09:37:00 UTC
Sorry for the spam. Confirming some bugs.
 Filter on "VINCENT CONFIRMS" to ignore.
Comment 3 Vincent Untz 2005-01-01 11:03:29 UTC
*** Bug 162291 has been marked as a duplicate of this bug. ***
Comment 4 Vincent Untz 2005-01-02 15:55:47 UTC
What we could do is add a GtkLabel-derived widget that acts like the one used on
the desktop to libpanel-applet. I'm not sure it's a good idea, though...

Mark: any comment on this idea?
Comment 5 Vincent Untz 2005-01-02 15:56:37 UTC
*** Bug 86952 has been marked as a duplicate of this bug. ***
Comment 6 Danielle Madeley 2005-01-11 09:53:09 UTC
Vincent, that might be useful. According to me, libpanel-applet does not have
API freeze, so perhaps we can still add this for G10, seeing as I claim it not
working is a bug, and not a feature. Plus, the code has already been written ;)
Comment 7 Jeremie Knuesel 2005-02-06 22:55:54 UTC
This is indeed annoying. The nautilus behaviour is very handy, but another (IMO)
good possibility would be to have a per-panel font property in the panel
parameter dialog that should be used by all menus and applets that reside on the
panel
Comment 8 Vincent Noel 2005-02-08 19:41:32 UTC
*** Bug 166597 has been marked as a duplicate of this bug. ***
Comment 9 Olav Vitters 2005-03-05 22:52:29 UTC
*** Bug 169335 has been marked as a duplicate of this bug. ***
Comment 10 Vincent Untz 2005-03-08 17:19:29 UTC
*** Bug 169624 has been marked as a duplicate of this bug. ***
Comment 11 Denis Jacquerye 2005-03-29 02:11:59 UTC
What about temporarily fixing this with a shadow on text? As subtitles do in
contemporary movies... or Nautilus with icons' text on the desktop? This is kind
of urgent. It looks really silly having a black background, playing with the
panel transparency and seeing text just fade out to black out.
Comment 12 Elijah Newren 2005-04-29 04:14:44 UTC
*** Bug 302276 has been marked as a duplicate of this bug. ***
Comment 13 Christian Kirbach 2005-07-12 11:58:54 UTC
COnfirming bug since everybody agrees work needs to be done.

I agree with comment #7 .However the general solution from comment #11 (the 
nautilus solution) is probably the best all-cases solution.
Imagine a black panel font and a colour gradient background panel image that 
fades from white to black. There will always be one part of the panel where the 
font colour matches the background colour.
Comment 14 Rodd Clarkson 2005-07-12 12:06:34 UTC
would it make sense to use the nautilus code, but to move this code to one of
the gnome libraries so that the panel and nautilus use the same code (or was
this always the plan)?
Comment 15 John Heidemann 2005-08-10 18:15:22 UTC
I would like to second comment #11 as a general solution.
For me, the problem is that in gnome-2.10, with a transparent panel
and a changing background image, sometimes the text is visible and sometimes the
contrast is insufficient.
Nautilus' handling of icon labels with shadows seems to be a proven fix.
Comment 16 Sebastien Bacher 2005-09-10 13:49:25 UTC
*** Bug 314916 has been marked as a duplicate of this bug. ***
Comment 17 Sebastien Bacher 2005-10-14 09:31:24 UTC
Same issue with the list of windows:
http://bugzilla.ubuntu.com/show_bug.cgi?id=17747

"When I turn on Transparentcy for the gnome-panel, I'm unable to read the names
of programs from the panel when they don't have focus. I submitted a screen shot
of the problem. I have three windows open, none of them have focus and although
I can see the icons on the bottom of the screen, I can't read the name of the
window.

http://bugzilla.ubuntu.com/attachment.cgi?id=4576
The problem in a picture"
Comment 18 Danielle Madeley 2005-10-14 11:30:53 UTC
KDE draws white around black. The means that is will always be visible (most
mouse pointers do something to this effect too).
Comment 19 Jean-François Fortin Tam 2005-12-06 04:22:12 UTC
A current problem annoying me with the gnome shadows is that they are shadows
instead of being "borders". What I mean is, (let's take the nautilus icon text
as an exemple), there is a black border around the white text, but only on the
lower-right side. IMHO it would be much much more readable if that was an
"all-around" border. 

Just thought you might know ;)
Comment 20 Vincent Untz 2006-01-24 19:29:42 UTC
Mass changing: milestone 2.12.x => milestone 2.14.x
Comment 21 Vincent Untz 2006-04-14 08:31:14 UTC
Small note: some people seem to want that the colors should also be themable. See http://gnomesupport.org/forums/viewtopic.php?p=51000#50997
Comment 22 Jordan Nash 2006-04-16 09:09:13 UTC
Here are a couple of ideas I haven't thought through, but might have merit:
What about just having less transparency behind the text? 

Maybe a poll could be taken where the panel decides that enough of the colors beneath it are too dark for the current forecolor to be readable so it flips the required forecolor, which all panel applets respect?

Comment 23 Sven Herzberg 2006-04-25 15:41:23 UTC
Re-targeting for 2.16 (and taking this bug).
Comment 24 Sven Herzberg 2006-04-28 11:57:45 UTC
This bug depends on bug 340015.

Once it's possible to set the text color, it should be possible to add a function to calculate a text color that should be well visible on the panel.
Comment 25 Luca Cavalli 2006-05-04 08:03:53 UTC
*** Bug 340597 has been marked as a duplicate of this bug. ***
Comment 26 Olav Vitters 2006-07-03 23:38:33 UTC
*** Bug 346504 has been marked as a duplicate of this bug. ***
Comment 27 Arthur Taylor 2006-08-07 01:33:40 UTC
As for a temporary solution, it is possible to individually set the clock's colour in a gtk rc file. A big hint of how to do this can be found in the clock applet's code:

if (first_time) {
                gtk_rc_parse_string ("\n"
                                     "   style \"clock-applet-button-style\"\n"
                                     "   {\n"
                                     "      GtkWidget::focus-line-width=0\n"
                                     "      GtkWidget::focus-padding=0\n"
                                     "   }\n"
                                     "\n"
                                     "    widget \"*.clock-applet-button\" style \"clock-applet-button-style\"\n"
                                     "\n");
                first_time = FALSE;
        }

        gtk_widget_set_name (widget, "clock-applet-button");

All that you have to do is put the following in a gtkrc somewhere (if you want the clock text to be white, else put another colour in):

style "panel-clock"
{
  fg[NORMAL] = "#FFFFFF"
}
widget "*.clock-applet-button.*" style "panel-clock"

and it works.
Comment 28 Benzo 2006-08-09 02:35:39 UTC
Perfect!!, thanks, it works. People what if you make a funtion to select the color of all the fonts in the gnome-panel? you could solve the problem until you get the answer you're looking for.
Comment 29 Arthur Taylor 2006-08-09 05:02:24 UTC
Well, other applets can be changed using different widget names. What follows is a list of other panel objects and associated names/classes that I've discovered (via google or grep)

"*WnckTasklist*" = Window List
"*WnckPager"     = Workspace Switcher
"*PanelMenuBar*" = GNOME Menu Bar
"*PanelWidget*"  = Some panel objects
"*PanelApplet*"  = Other panel objects
Comment 30 Tomasz Torcz 2006-08-09 06:48:29 UTC
Text on GTK progress bars with Clearlooks already change colors of characters for goo visibility. See for example here, in lower right part: http://www.ossblog.it/uploads/clearlooks_cairo_gtk.jpg  (random googled screenshot).
Comment 31 Sebastien Bacher 2007-04-16 07:55:59 UTC
*** Bug 430155 has been marked as a duplicate of this bug. ***
Comment 32 Susana 2007-10-06 10:03:26 UTC
*** Bug 481664 has been marked as a duplicate of this bug. ***
Comment 33 Mikayla Hutchinson 2007-10-11 21:30:00 UTC
Arthur Taylor: Please don't wildcard "*PanelWidget*" like that, as not every GTK widget with "PanelWidget" in its name is in the GNOME panel. This can impact on other apps (such as MonoDevelop, where we have configuration panel widgets), and unfortunately this technique seems to have spread around a bit.