Re: pseudo transparency

[Owen Taylor <otaylor redhat com>]

Sasha Vasko <sasha aftercode net> writes:

> On Friday 11 January 2002 17:56, Owen Taylor wrote:
> > >
> > > Iportant problem here is that you leave shared resource unprotected
> > > and unmanaged. Its as if you allowed client apps to set current
> > > colormap as they like.
> > >
> > > Colormaps are actually another part of this particular issue, since it
> > > would be desirous for clients to obtain the colormap/visual with which
> > > such root pixmap was rendered.
> >
> > This is indeed somewhat of an issue. I don't think it's really worth
> > the complexity of a whole new protocol, since even negotiating this
> > doesn't provide a nice user interface to the user. Making sure
> > that the background is set by only one app is the responsibility
> > of the person configuring the desktop.
> 
> Like that we can blame anything at all on the user.
> I could compile you nice big stack of bugreports and support requests related 
> to this specific issue, since ESETROOT method is rather prone to 
> misconfiguration. Don't forget also that applications tend to have bugs, and 
> letting them play with such an important resource, that is used by many 
> others, is not a good idea.

And window managers are applicatons too, right? :-).
 
> The problem is that you have shared resource at hand, and like anything else 
> it has to be managed by window manager. And ICCCM compliant/recommended way 
> of doing it is to use selection. Not that I'm inventing a wheel here.

Yes, in general I'm in favor of using manager resources to lock shared resources,
but I just don't see the benefit to a change here. We have a existing "standard"
that when used properly:

 - Makes sure that no pixmaps are leaked
 - Allows reliable notification as to what the current background is

What it doesn't provide to the user is the ability to configure their background
in one place and make sure that it will show correctly. But there is nothing
we can do about that at this level:;
  
 * All a locking mechanism does is change "last wins" to "first wins". It
   doesn't guarantee that the one the user has configured wins.

 * The "big window" approach of Konqueror and Nautilus -- recommended in the WM
   spec -- means that setting the root window is often insufficient anyways,
   so just because you get the selection, doesn't mean that you are setting the
   background that the user sees.

I think it has to be up to the "desktop integrator" to make sure that there is
a clear place to set the background and that works.

I don't think the benefits of a change would be worth: 

 * Having to modify all apps that use the current mechanism
 * Making it impossible to have "run and exit" background setters
 * Requiring some quite complex code in every app that wants to set the background.

Regards,
                                        Owen