Works for me...

Works for me too.

I seem to remember having this problem when I tried it under Phoebe. 
I'll add myself to the cc list and try to remember to check this out
when I'm on that Phoebe system again.

Elijah: did you try this on Phoebe ?

Doh!  Thanks for the reminder.  I'll try it out tonight or tomorrow
morning.

  /me engraves the reminder into his hand...

Unfortunately, it appears that RedHat's bugzilla is down so that I
can't read the original report right now.  So, I'll just try to be
very specific about all the steps that occur upon login when I have
selected a transparent panel and am using Redhat's Phoebe-1 Beta:

When Gnome is first launching after login from GDM, the screen at
first turns completely blue (single shade--no gradient).  When the
panel launches a few seconds later, it has a gray background (the
default color) for a split second but quickly changes to black.  At
this point, the icons are added as well as the applets that ignore the
transparent panel (using instead a gray background--namely, Window
List, Workspace Switcher, Clock, and Notification Area).  A few
seconds later, just before the icons appear on my desktop, the desktop
background is changed to a gradient of two blues--and the background
of the panel is updated to the same background shortly thereafter
(note that this paints over the icons on the panel so that they look
like they have disappeared but leaves the gray background applets
alone).  Just under a second later, after all the icons are on the
desktop, the desktop background is updated to the picture of a
dragonfly (a predominantly green background), but the panel is not
updated.  If I click on the background and select "Change Desktop
Background", then approximately 2 seconds after the window appears to
allow me to change the background, the panel's background is updated
to match that of the real background (i.e. the background of the panel
becomes the bottom part of the dragonfly picture).  The icons are
still visually missing from the panel, but I've discovered that it's
fairly simple to bring them back--I just have to move the mouse over them.

Would it be helpful to attach a couple screen shots?  Print-Screen
seems to be disabled as a keybinding now, but I was able to get a
couple screen shots after the login sequence was complete (one which
shows the dragonfly with the blue gradient panel, one which shows the
panel background correctly updated (other than the non-conforming
applets) after selected "Change Desktop Background", and one which
shows the icons have reappeared after I moved the mouse over them).

I haven't tried GNOME2.2 or Redhat's Phoebe 3 yet, and I suspect they
may fix these problems (especially with the rewrites of the background
drawing in nautilus that I've heard about).  I'll give it a try and
let you know.  Feel free to ping me if I haven't reported back within
a week (or if you just need further explanations).

While I'm working on this, I'm going to set version->2.1.x, set
priority->high (it's a cosmetic bug that really sucks--but I can
understand if someone else marks it back down to priority->normal),
leave severity at normal, add the GNOMEVER2.1 and bugsquad keywords,
and I'll wait until I've tried Phoebe3 to decide whether to mark it as
new.

Okay, I just tried this with Redhat's newest Beta, Phoebe-3.  In this
beta, the step of drawing a background with a gradient of two blues is
skipped entirely (unless no background picture has been selected). 
When the background for the desktop is drawn by nautilus, the panels
are also updated, although there is a two second lag or so.  Also, the
panel icons are not painted over by the desktop background.

Thus, the core part of this bug has been fixed--the panel gets the
right color (albeit with a slight delay) without any manual user
intervention (such as trying to change the desktop bacground again);
and the panel icons remain visible (and don't require a trick like
moving the mouse over them to get them repainted).

However, this bug can stay open as a request for enhancement.  The
fact that the panel background starts black (when there's a blue
background and the panel is supposed to be transparent) is less than
optimal.  Also, the two or so second delay between drawing of the main
background and the drawing of the background of the panel might be
able to be improved.  This may be a WONTFIX, according to the
maintainers preferences, but it is a small annoyance that could
eventually be improved.


Because of all this, I'm going to drop severity->trivial and
priority->normal.  I'm also going to update the version to 2.2.x and
mark as new.

This might be fixed with a change I made at the beginning of 2.13.x. If someone
has time to verify... (using the milestone to try to not forget about it).