Created attachment 7003 [details]
Screenshot of the desktop look i was refering to

Ps, what would be ideal in this case (maybe it works for all cases?)
is if the background color of the window list is not a set color, but
a + something % darker on pressed in, and something% lighter when in
the raised state.

This way it looks the same when using the standard grey background,
but is modified along with the color scheme of the panel when that is
a non default color (and still look prety damn good)

(ps, this is only for the window list, the other applets should just
have a transparent background canvas)

ofcource if that is to much to do in the short timeframe to gnome2, a
color setting for raised/lowered states of the windowlist would tie me
over just fine to ;-)

*** Bug 73744 has been marked as a duplicate of this bug. ***

Wanted to comment that this is also a problem when setting a pixmap 
as the background of a panel. 

Using the patch from bug 73440, i can now correctly set the background
color of the panel (and actualy restart the panel without crashes).
(cvs checkin pending?)

However, this allows to expose more inconsitencies with the gnome panel:

First of all, see the shot of the panel i will be attaching, with the
panel set with a black background color. To this panel i have added
_every_ applet i can find in gnome-panel/gnome-applets. (except window
list since it didnt fit any more, but which also doesnt take the color
setting)

This offsets very nicely which applets still have a default background
color, and not the panels background color.

Secondly, Some applets are _not_ visible in the screenshot, since they
did take the background color, but there text is black as well (Gnome
Menu applet only shows its foot, inbox monitor is invisible).
(the 'clock' applet is located between the eye's and the batt-stat
applets, and the large black area to the right of the panel is the 
menu bar applet)

Also, it exposes a problem with the 'hightlight' color of the panel.
When i click the panel now, the background color underneath the clock,
  mixer and gnome menu applet's backgrounds turns back into the
'highlight color', which is grey.

This is always true for the window switcher, where its surface is
always default grey, 'highlighted grey' or 'selected grey'.

A lot of borders around applets also seem to retain there default grey
edges. (wanda, cd player, char picker, keyboard selector, workspace
selector, etc).

It would be great if this behaviour can be fixed for atleast a basic
set of applets (clock, mixer, desktop selector, windowlist, battstat?)

Note: all applets that have only a pixmap as a surface (such as
launchers, drawers, logout buttons, etc) work properly with
backgrounds, as there pixmap's are already transparent.

When the basic problems with the applets regarding background color is
fixed (ie: adopt the correct color, do not use grey outlines around
the applets), there seems to be another problem to solve.. A way to
deal with the fact that 'selected color' and 'highlight color' (now
darker and lighter grey) should _not_ be constants. You can either try
to be inteligent and use "highlight color == color + some_brightness",
or you can take the easy way out and make the selected and highlight
colors configurable ;-)

Also, a configuration option for 'text color' would solve the problems
of some applets not showing up on dark or black backgrounds.


A last option would be to remove the posibility of setting a
background color all together, and use the gtk theme's color scheme's,
but in my opinion that would be a shame, since it would disallow some
real nice desktop looks.

Created attachment 7104 [details]
Shot of a black panel with all applets on it

Adding louie to CC. 

Louie: can u take a look @ this and adjust priority/severity, and
posibly add 'triaged' to it?

Also if you have any good sugestions of other info i can supply, i'm
open to sugestions ;-)

This is mainly cosmetic but a big ugly cosmetic one. Adding the
1.x-parity keyword.

An easy but perhaps unpopular fix to this could be to just rip out the
functionality of changing the background to a color or pixmap and just
make it based on gtk themes. I guess this would raise hell with the I
want to customize everything unix crowd though. Sure would do a lot
for consistency though.

bordoley@msu.edu, though i agree it seems like a posible solution (in
the leage of 'if we do not ship with a panel, there wont be any bugs
in it'), i think it would severely limit the ability to customize a
desktop. Not just from a 'wow im young and i need a l33t desktop'
P.O.V, but also the ability to make proper nice looking desktops
(think of Win XP as (a horible) example). Also shiping without that
ability would be a horible fearture regression from the 1.4 gnome
platform.

Anyways, i hope it won't come to drastic 'solutions' like that yet 

Agreed with Chris on this count, Dave- this would be a big regression
from 1.4 to just rip out. It's one thing when you're ripping such
things out of nautilus (where they basically aren't used) but it's
quite another to go ripping them out of the panel.

Okay, listen ... the funcionality is there - i.e. the panel tells the
applets what background it needs to be drawing. So there are thre
classes of bugs that could arise from this

1) The panel isn't sending the right info -> panel bug
2) The applet isn't recevining the info correctly (or not parsing it
correctly) -> libpanel-applet bug
3) The applet ignores or doesn't handle correctly the backround
changes -> an applet specific bug ...

I'm tempted to close this bug and ask that individual bugs be filed
...

Luis ?

Mark, i believe there are a few more issues here.

If you look at my comment at 2002-03-11 11:08, it describes most of
them, but to summerise:

1) The applets still use the gtk theme prelight/highlight color. This
is not apropiate if the default background color is set to anything
but the theme's background color (ie: pick any color or background image)

2) If the background color chosen is to dark, the text will not be
readable, and there's no option to choose font color for the panel

3) Posible bugs as described in your reply. 

I gues the simple way of solving 1 & 2 is by making a couple of font &
color selectors. (for prelight/highlight and font color). The
difficult way of solving things would be trying to gues the correct
values, but this seems undoable (@least in a relativly short time frame).

If you need seperate bugs file, i would sugest one bug for the panel
that it needs a prelight/highlight/font selector, and a bug per applet
for:
- Needs to pick up color from panel
- Needs to pickup pre/highlight colors and font 

I know this is probably a shit load of work, but as mentioned before,
a prety serious issue.

Eck. We shouldn't be having to pick additional colors and such. That's
broken, and a shit-ton of additional work given that not only would
there have to be a GUI, but documentation, screenshotting, etc. I
think chris's 1 and 2 are best deal with (at this point) by saying
'don't make themes that suck that way.'

So... I'm going to go with Mark's suggestion. We close this. If
individual applets are not respecting the information currently
provided by panel, as per mark's #3, they need bugs opened on them.

Louie, think about it, how can we then deal with applets such as the
window list? This would mean a perminent dis-coloring on your panel
(since the active window's  button is always pressed down and uses a
alternate color)

Also, it doesnt 'fix' the issue of unreadable text with the background
color doesnt have enough contrast with the text color.

In the end that would mean you would go from severely broken to
partialy broken, but not yet fully usable ;-/

So should individual bugs be filed for the wla, wsa, menubar etc? 

dave: I'd say yes, but I'm not /exactly/ the expert here :)