Compiz's Panel shadows show on top of other windows

Confirmed. This is annoying.

I don't know, I think it makes sense, the panel is always 'active' and 'above' the current window

This is the expected behavior.

This is not the desired behavior. It presents a usability problem (window title bar text and icon are partially obscured). See Bug 184551, and in particular, take a look at the screenshot.jpg presented by nxsty. Having the panel at the "same level" of windows is the intuitive, more usable, and more aesthetically pleasing arrangement.

To clarify, the top-most window and the panel should be on the same plane.

A hackish way to fix this would be to disable panel shadows by default in compiz and draw fake (non-composite) shadow on the desktop wallpaper beneath the panels. This would look right and would probably be a lot easier than fixing compiz.

This would look awful if the user resizes, moves, or removes his/her panels.

The shadows would of course be drawn corresponding to the size and position of the panels...

But anyway, this might already have been fixed in compiz. The release included in jaunty doesn't seem to have this problem.

"But anyway, this might already have been fixed in compiz. The release included in jaunty doesn't seem to have this problem."

Absolutely not true for me. I am up to date with the Jaunty releases. This "bug" is still present. nxsty, I suggest you verify your settings are at "auto" only for window types, and turn up the opacity and radius settings, then confirm you no longer see this behavior.

You're right, it was just the dark "New wave" theme that made it difficult to see. The problem is still there.

I must agree with Chris
-it has not been fixed
-it is a valid bug

imagine...
the shadow settings were set to draw somewhat large shadows, like in macintosh. this is possible. then the shadow would obscure the adress bar of a browser, and so on...
how can a shadow be drawn on a window that i am currently interacting with?

Why is this marked as invalid?

1. This affects the default configuration of Ubuntu.
2. It is exceedingly ugly.
3. The fix is a trivial configuration change: replace "any" by "!name=gnome-panel" in "Window Decorations" options.

This looks like a prime candidate for a paper cut.

And a better fix: use "!(class=Gnome-panel)".

This is a simple fix, use of "!(class=Gnome-panel)" as default, should solve this

That is a working solution. I would encourage an elegant solution which follows the model of OS X's menu bar (the equivalent of a panel in GNOME). The menu bar casts a shadow, however, it does not cast it upon any other windows than the root window (desktop). The difference is subtle, but beautiful. See attached screenshot.

Ok , i take back what i said before...

(any) & !(type=Dock) , is the better setting .

Since this *allows the drop down menus to have shadows and only removes the shadow from the panel* .

David , could you take a decision on this?
This can be fixed by simple exclusions in compiz settings.

@all: could someone provide a screenshot of the default behavior? So that David can take a design decision.

@mav_v: disabling the panel shadow in compiz is over-the-top, here are some images:

http://img441.imageshack.us/img441/2964/compiz.jpg
http://img441.imageshack.us/img441/349/compizwithexclusion.jpg
http://img22.imageshack.us/img22/3686/metacitycompositor.jpg

the right behavior is displayed by the metacity compositor (enable compositing_manager in gconf/apps/metacity/general), see third screenshot

@Andreas Berger:
IIRC , that works only if metacity is the window manager , right?
If compiz it the window manager , panel throws shadows over the windows.

Or is there an equivalent setting in compiz for compositing_manager?

@mac_v
unfortunately not.

the thing is: the panel is kind of an exception from other windows, because usually, if a window is on top of another window, we want it to cast its shadow upon the window underneath, but the panel and the active window should be on an equal level, for both are a potential candidate for interaction in that situation. (see mac os x)

the solution would be drawing the shadow of the panel behind other windows although the panel itself is not (otherwise we would have the window's shadow upon the panel which would be at least as wrong).

The panel should cast a shadow on the desktop, but not on the windows. The panel is not above the windows -- you can verify this by trying to drag a window under the panel; you will see that the panel and windows are on the same plane and collide with each other. This collision with shadow is incongruous. Also, the shadow is meant to be a subtle effect, but its effect is amplified far beyond subtlety when a window is maximized. Maximized windows are a common occurrence, so it's reasonable for us to ensure that the shadow is not cast on windows. I fail to see what benefit we lose if we make this change.

Yes! Make Compiz do this one!: http://img22.imageshack.us/img22/3686/metacitycompositor.jpg

@David: i think we all agree to make this change, but now it has to be implemented in compiz, it can't be done by changing a simple setting as far as i understand it.

one detail btw: technically, at this point, the active window is actually behind the panel: use the expo plugin (windowskey + E) to zoom out, then move a window beyond the panel and see it is actually behind the panel. since you can't usually do that i would consider that another small bug, but it unveils that compiz has the panel above the active window.

Travis, I understand that this behavior is expected but there is a strong sentiment that the expectation is wrong. Can you please take another look at confirming this?

Last time I looked into this it required a bit of a hack where you draw the shadows in two stages. The first stage is drawing the panel shadows only then running through the windows a second time drawing shadows for everything else. Upstream was very resistant to such a change happening there and I actually think the next release of compiz (when/if if ever happens) would make such a change impossible to do in this way. Not really sure what to do here to be honest.

The front window + panels occupy a single plane. All windows beneath have
their own plane, and menus have a plane on top. How easy is it to shoehorn
that logic into Compiz?

2009/8/20 Travis Watkins <email address hidden>

> Last time I looked into this it required a bit of a hack where you draw
> the shadows in two stages. The first stage is drawing the panel shadows
> only then running through the windows a second time drawing shadows for
> everything else. Upstream was very resistant to such a change happening
> there and I actually think the next release of compiz (when/if if ever
> happens) would make such a change impossible to do in this way. Not
> really sure what to do here to be honest.
>
> --
> Compiz's Panel shadows show on top of other windows
> https://bugs.launchpad.net/bugs/91786
> You received this bug notification because you are a direct subscriber
> of the bug.
>

That actually breaks at least one specification on how window managers work. The panel is always on top of everything except another panel. Thus the hack for drawing shadows instead.

@ Travis Watkins
"The panel is always on top of everything except another panel"
The panel as well as the active window are both a candidate for user interaction, hence none of them should be covered by *anything*. with a big enough shadow this becomes a usability problem. metacity proves it can be done, see third screenshot above.
(i know that technically the panel was always on top, but it didn't feel this way until we had shadows, and it shouln't feel this way)

Can anyone find the upstream bug for this? I cant seem to find one !
This bug has been for ~2yrs and hasnt been sent upstream?

@Andreas Berger:
Travis raises a valid concern that upstream is blocking this bug , and in future version might even make the hack impossible !

IMO , its better to reason it out with upstream devs and do something proper about it [hack or a proper fix]

Assigning this to Travis after discussing with him.

An FYI to all , We have 2 options:
1: ask upstream to hack the shadows appropriately [tough]
2: Let Ubuntu carry a small hack on its own [easier] ;)

If anyone can convince upstream to fix this , it would be better . You can get more of their attention on irc rather than bug reports ! Thanx in advance.

Apologies to Travis, i was a bit too quick to respond and overlooked your first post

Upstream is looking into a way to fix this properly in compiz++ (will be compiz 0.9 when released) but for now the linked branch fixes the problem for us.

compiz (1:0.8.2-0ubuntu16) karmic; urgency=low

  [ Travis Watkins ]
  * debian/patches/015_draw_dock_shadows_on_desktop.patch:
    - change decoration plugin to draw dock shadows only on the
      desktop window instead of on top of all other windows

This has been fixed.

compiz (1:0.8.2-0ubuntu16) karmic; urgency=low

  [ Travis Watkins ]
  * debian/patches/015_draw_dock_shadows_on_desktop.patch:
    - change decoration plugin to draw dock shadows only on the desktop window instead of on top of all other windows

Is there a way to revert this to the old behavior? It really looks horrible with this "fix".

No, there is no way to revert to the old behavior.

What was this patch applied to? Compiz? Would I be able to download the source and revert this to the old behavior?

Sure, if you grab the source package (`apt-get source compiz`) and edit the debian/patches/series file to comment out 015_draw_dock_shadows_on_desktop.patch then build the package (`debuild binary`) you'll end up with a package that doesn't have this feature. You'll want to raise the ubuntu version in debian/changelog though so the archive version doesn't upgrade over yours.

Thank you for patching this. I wonder if Fedora could pick this patch up.

nate8nate, why does it look bad? Do you like the shadow covering your window bar?

I never thought of this as a problem. The old behavior resulted in a very nice 3D effect of the top panel floating above the window title bar. It does not obscure it at all. See attached screen shot.

I find it very hard to distinguish the status bar and the bottom panel. The shadow never on the top never bothered me because I use a dark titlebar. The shadow also helped give the panels a 3D look. This should be toggle-able in CCSM.

Perhaps in lucid we'll have a better setup for this so you can turn it on and off but that won't happen for karmic.

I'm quite a newbie on Linux, but still found quite a simple and elegant solution with no need for patching. In CompizConfig-Settings-Manager I activated "Window Rules" and set "Below -> class=Gnome-panel". Now the panel shadow appears exactly as on the Mac below the windows, but windows still won't overlap the Panel, just the way it should be.

Agreed with Martin G Miller and nate8nate. Bottom panel and fullscreen applications have the same color so it is impossible to tell where the line is...

I don't understand why do you guys always have to enable/disable stuff just because a few doesn't like it or some other OS doesn't do it that way. OK, it is completely reasonable that you may not like something. I understand that. But why does it always have to end up being a "bug"? There are so many similar situations happened to me before; so many features ("bugs") that I found invaluable were "fixed" in the past and forced me go back to a previous release. I really enjoyed panel shadows casting on my fullscreen windows but I can't get it now! Maybe I should take the time and file it as a bug because I liked it that way...

atari75xl:

I like your solution, but there is a slight problem (bug in current compiz): panels marked "below" cannot be accessed by keyboard with the 'switch between panels' shortcut.

nate8nate:

I understand your problem completely. The bottom panel is a special case. Unlike OS X, Gnome uses the standard window colors for their panel. So the panel and windows blend together.

I only use the bottom panel to hold launchers, so I set it to transparent color (taskbar on top panel). This helps tremendously. Like an OS X dock, there is good distinguishment. (It's even better when the *window* casts a shadow on this dock-panel).

I see your problem (can't tell the two apart), and for that reason, I can understand why the bottom panel should have the proper shadow.

This is a bummer, since it's really kinda strange on the top panel. Perhaps different shadow settings could be used on each panel.

Or, maybe Ubuntu could try either A) get rid of the dumb default double-panel layout, or B) use different colors for panel than for windows (the shiki-colors themes do this pretty well).

By applying this patch on the whole "dock" window match, the clock-applet's drop-down info window (which is "dock" as well) does not cast shadow over windows that are bellow it, causing worse orientation on the desktop (which are the shadows decorations designed to clarify besides their aesthetic feel); the clock-applet's drop-down window does not even have window-decorations, so the situation becomes even worse. The patch should instead by applied on the panel only, kind of "panel$" window match or whatever it could be to keep it international...

Pretty sure any match for gnome-panel is going to match the clock applet window, In any case, I'd say it is the clock applet that has the bug as it should not mark this window as a dock type window. Metacity implements their hack for drawing shadows like this pretty much the same way we do and they have this exact same issue. Only docks should be marked as docks.

As far as I know only the clock applet and the invest applet have this problem.