The _COMPIZ_WALLPAPER_SUPPORTED hint is used by the Compiz wallpaper plugin to
indicate that it would like to draw the desktop background, so in response
something such as Nautilus should not. This patch, coupled with a patch to
nautilus (to set an RGBA colormap on the desktop window), doesn't draw the
desktop background when the hint is set, and if it is changed switches modes of
operation.

It is useful for the wallpaper plugin to enable different backgrounds on
different viewports (i.e. different sides of the cube).

Created an attachment (id=89405) [details] [review]
Patch for libeel

Created an attachment (id=89406) [details] [review]
Nautilus patch

Hi, sorry it took us so long to get around to commenting on this; Eel doesn't
receive as much attention as Nautilus does, and this bug pretty much fell off
the map. Anyways, we are currently discussing the best way to implement this
for 2.24, and so I'm moving the bug to Nautilus and targeting it for the next
release. 

A few points: We should use GDK to test if compositing is available and we need
to monitor the composited-change signal on the GdkScreen so we can revert to
the old behavior if the user doesn't have compositing. We also should stop
drawing the background in the event that compositing is available, and just let
gnome-control-center or the window manager draw the background (as per bug
#48004).

It was also discussed that we need some input from the WM Spec team on what
atom to use for multiple backgrounds so that we're not carrying around a hack
just for Compiz. Christian Neumair sent this mail to that team:
mail.gnome.org/archives/wm-spec-list/2008-March/msg00017.html

Lets get this in for 2.24!

*** Bug 524846 has been marked as a duplicate of this bug. ***

I am not sure bug 524846 is a duplicate of this bug. 524846 is not limited to
compiz. There should be an option "transparent background" in nautilus
configuration next to the option "Show desktop" in gconf-editor (it would also
be best if these options were accessible from the "appearances preferences"
GUI). "transparent background" would make nautilus draw the icons on top of a
root window whose content would be managed by another program (mplayer, compiz
wallpaper plugin ...). At the moment it is not possible to have a movie in the
background or to set different backgrounds on the faces of the compiz cube
without giving up on desktop icons ("show desktop" option turned off).

This bug isn't limited to Compiz either, it's just badly titled. "Transparent
background" is most certainly a dupe of this bug; when fixed, we'd simply
composite the desktop icon container onto the existing background (which can
then be drawn by whatever). 

Updating summary.

I'm voting for this enhancement.  Considering I prefer a desktop with icons,
this is the only way I'm aware of getting for compiz-fusion's wallpaper plugin
to work for multiple workspace wallpapers.  I'm too scared to try the patches
for Gnome 2.20 given I'm using 2.26, especially with the reports of the patches
not working on 2.22.

Is it inapropriate to ask for a dev status update (or request a change/removal
of the target milestone)?

*** Bug 590500 has been marked as a duplicate of this bug. ***

Voting for the enhancement, too, which is not yet in 2.26 in Debian. Wallpaper
in Compiz is pretty much useless without transparent Nautilus desktop, and I'd
hate to lose the desktop icons.

The milestone for this bug should be set appropriate.

There are thousands of users who would be pleased by this.

*** Bug 611218 has been marked as a duplicate of this bug. ***

Ah, okay, I created the dup. I'd love to see any way to enable this behaviour
in Nautilus, even if it's just a config option. I was also wondering what a
realistic target milestone might be (since the one in the bug write-up can't
possibly be correct ;-) ). Also, I'm thinking of taking a stab at patching this
myself -- if anyone more familiar with the codebase wanted to point me vaguely
in the right direction, it would be appreciated.

I'd also like to vote for this! This was opened three years ago, and it appears
that a fix has already been issued for v2.20. Would be nice if this was
included in mainline.

Come on...

Changing component as part of ongoing bug reorganisation work.

We should revisit this while cleaning up the background in 3.2.

(In reply to comment #16)
> We should revisit this while cleaning up the background in 3.2.

Cosimo: Time to do this now?