Compiz's Panel shadows show on top of other windows
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| | One Hundred Papercuts |
Low
|
Unassigned | ||
| | compiz (Ubuntu) |
Low
|
Travis Watkins | ||
Bug Description
Binary package hint: compiz
This looks particularly unsavoury when a window is maximised. You get this strange unnatural shadow at the top of the window's title bar.
Perhaps the panel should follow the rules of all other windows, i.e. its shadows only drawing on top if it is the active (on top!) window.
ProblemType: Bug
Architecture: i386
Date: Mon Mar 12 22:49:34 2007
DistroRelease: Ubuntu 7.04
Uname: Linux flash 2.6.20-9-generic #2 SMP Mon Feb 26 03:01:44 UTC 2007 i686 GNU/Linux
| MartinE (martin-engbers-gmx) wrote : | #1 |
| VF (vfiend) wrote : | #2 |
I don't know, I think it makes sense, the panel is always 'active' and 'above' the current window
| Changed in compiz: | |
| status: | Unconfirmed → Confirmed |
| Changed in compiz: | |
| importance: | Undecided → Low |
| Travis Watkins (amaranth) wrote : | #3 |
This is the expected behavior.
| Changed in compiz: | |
| status: | Confirmed → Rejected |
| Chris Lasher (chris.lasher) wrote : | #4 |
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.
| Alexander Jones (alex-weej) wrote : Re: [Bug 91786] Re: Compiz's Panel shadows show on top of other windows | #5 |
To clarify, the top-most window and the panel should be on the same plane.
| Simon Strandman (nejsimon) wrote : | #6 |
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.
| Chris Lasher (chris.lasher) wrote : | #7 |
This would look awful if the user resizes, moves, or removes his/her panels.
| Simon Strandman (nejsimon) wrote : | #8 |
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.
| Chris Lasher (chris.lasher) wrote : | #9 |
"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.
| Simon Strandman (nejsimon) wrote : | #10 |
You're right, it was just the dark "New wave" theme that made it difficult to see. The problem is still there.
| Andreas Berger (andi-berger) wrote : | #11 |
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?
| The Fiddler (stapostol) wrote : | #12 |
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.
| The Fiddler (stapostol) wrote : | #13 |
And a better fix: use "!(class=
| Vish (vish) wrote : | #14 |
This is a simple fix, use of "!(class=
| Changed in hundredpapercuts: | |
| status: | New → Confirmed |
| Chris Lasher (chris.lasher) wrote : | #15 |
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.
| Vish (vish) wrote : | #16 |
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* .
| Vish (vish) wrote : | #17 |
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.
| Changed in hundredpapercuts: | |
| assignee: | nobody → David Siegel (djsiegel) |
| importance: | Undecided → Low |
| milestone: | none → round-10 |
| status: | Confirmed → Triaged |
| Andreas Berger (andi-berger) wrote : | #18 |
@mav_v: disabling the panel shadow in compiz is over-the-top, here are some images:
http://
http://
http://
the right behavior is displayed by the metacity compositor (enable compositing_manager in gconf/apps/
| Vish (vish) wrote : | #19 |
@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_
| Andreas Berger (andi-berger) wrote : | #20 |
@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.
| Rich Jones (richwjones) wrote : | #22 |
Yes! Make Compiz do this one!: http://
| Andreas Berger (andi-berger) wrote : | #23 |
@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?
| Changed in compiz (Ubuntu): | |
| status: | Invalid → New |
| Changed in hundredpapercuts: | |
| assignee: | David Siegel (djsiegel) → nobody |
| milestone: | round-10 → round-9 |
| Travis Watkins (amaranth) wrote : | #25 |
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.
| Alexander Jones (alex-weej) wrote : | #26 |
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:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
| Travis Watkins (amaranth) wrote : | #27 |
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.
| Andreas Berger (andi-berger) wrote : | #28 |
@ 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)
| Vish (vish) wrote : | #29 |
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]
| Vish (vish) wrote : | #30 |
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.
| Changed in compiz (Ubuntu): | |
| assignee: | nobody → Travis Watkins (amaranth) |
| status: | New → In Progress |
| Changed in hundredpapercuts: | |
| status: | Triaged → In Progress |
| Andreas Berger (andi-berger) wrote : | #31 |
Apologies to Travis, i was a bit too quick to respond and overlooked your first post
| Changed in compiz: | |
| status: | Unknown → Confirmed |
| Travis Watkins (amaranth) wrote : | #32 |
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.
| Travis Watkins (amaranth) wrote : | #33 |
compiz (1:0.8.2-0ubuntu16) karmic; urgency=low
[ Travis Watkins ]
* debian/
- change decoration plugin to draw dock shadows only on the
desktop window instead of on top of all other windows
| Changed in compiz (Ubuntu): | |
| status: | In Progress → Fix Released |
| Changed in hundredpapercuts: | |
| status: | In Progress → Fix Released |
| Vish (vish) wrote : | #34 |
This has been fixed.
compiz (1:0.8.2-0ubuntu16) karmic; urgency=low
[ Travis Watkins ]
* debian/
- change decoration plugin to draw dock shadows only on the desktop window instead of on top of all other windows
| nate8nate (nate8nate) wrote : | #35 |
Is there a way to revert this to the old behavior? It really looks horrible with this "fix".
| Travis Watkins (amaranth) wrote : | #36 |
No, there is no way to revert to the old behavior.
| nate8nate (nate8nate) wrote : | #37 |
What was this patch applied to? Compiz? Would I be able to download the source and revert this to the old behavior?
| Travis Watkins (amaranth) wrote : | #38 |
Sure, if you grab the source package (`apt-get source compiz`) and edit the debian/
| Jud Craft (craftjml+ubuntulp) wrote : | #39 |
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?
| Martin G Miller (mgmiller) wrote : | #40 |
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.
| nate8nate (nate8nate) wrote : | #41 |
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.
| Travis Watkins (amaranth) wrote : | #42 |
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.
| atari75xl (mi-cha) wrote : | #43 |
I'm quite a newbie on Linux, but still found quite a simple and elegant solution with no need for patching. In CompizConfig-
| agonified (hakanakkan) wrote : | #44 |
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...
| Jud Craft (craftjml+ubuntulp) wrote : | #45 |
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).
| plopp (jirihusak) wrote : | #46 |
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...
| Travis Watkins (amaranth) wrote : | #47 |
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.
| Changed in hundredpapercuts: | |
| assignee: | nobody → artur bryczek (arturbryczek) |
| Changed in hundredpapercuts: | |
| assignee: | artur bryczek (arturbryczek) → nobody |
| no longer affects: | compiz |


Confirmed. This is annoying.