GNOME Bugzilla – Bug 103287
Transparent gnome panels does not get the correct background on startup
Last modified: 2015-03-24 14:48:30 UTC
Bugzilla-Product: gnome-panel Description: Please see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=80854 for the original bug report. ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-01-12 21:15 ------- Reassigning to the default owner of the component, gnome-panel-maint@bugzilla.gnome.org.
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).