GNOME Bugzilla – Bug 516088
No drop shadow on panel after login
Last modified: 2020-11-06 20:05:31 UTC
When using the compositor, the panel doesn't get a drop shadow after login. One must manually restart metacity for this to work, restarting the panel is not enough. I this was mentioned on the blog earlier, but I decided to properly file it as a bug so it isn't forgotten.
Hm. This works for me. Iain, any ideas why this might fail?
Another Debian user have reported similar behaviour, http://bugs.debian.org/472109 I wonder if this bug could be specific to Debian in some way?
Not debian specific (same issue with archlinux). maybe could be related to the startup order, (before metacity, than panel, or viceversa)
Restarting a panel (when it has a shadow) doesn't work, metacity needs to be restarted for the shadow to return. So I don't think it has anything to do with startup order?
That's true, but if you run metacity after the panel it should work... isn't it? Btw I've just tried to killall metacity, -panel has shadows-, killall gnome-panel, -no shadow-
Note that in GNOME 2.22 the panel has a little animation on its start-up. Top and bottom panels (default layout) are initially placed outside the screen edges, then they "slide" on place. I remember in 2.21.x releases the panel shadows was fine, starting to disappear after this panel animation commit. PS: compiz (on my ubuntu hardy) works fine with animation too.
I tried downgrading gnome-panel to 2.20, with no difference. So that's probably not it.
Its a race condition between metacity discovering the desktop window and the window registering itself as a desktop.
still having this with metacity 2.23.21
I got the same problem with metacity 2.24 under fedora 9/rawhide. A simple restart of metacity through "pkill metacity" works it around.
Vuntz told me this bug is related with the fact metacity is registering itself before it is ready. Maybe fixing the other bug will have positive effects here.
(In reply to comment #11) > Vuntz told me this bug is related with the fact metacity is registering itself > before it is ready. Maybe fixing the other bug will have positive effects here. > What bug exactly? Is there a bug report? thanks.
*** Bug 570810 has been marked as a duplicate of this bug. ***
Still the issue from various PCs and distro... basically we have to start metacity after the panel...
Although almost 2 years have passed since the last comment in this bug report and the issue is still there. Would there be a way to fix the race condition? Besides the "sleep X; metacity --replace" procedure. Even though this bug report is treated as normal priority it would be nice to have it fixed.
Hi, I too experience this, a workaround is also to turn compositing off and on again (cit.): gconftool -s /apps/metacity/general/compositing_manager --type bool false gconftool -s /apps/metacity/general/compositing_manager --type bool true Here is the ubuntu bug about that: https://bugs.launchpad.net/ubuntu/+source/metacity/+bug/269670 Thanks, Antonio
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years. If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/ Thank you for reporting this issue and we are sorry it could not be fixed.