Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

On Thu, 2007-10-04 at 13:20 +0200, Lubos Lunak wrote:
> On Wednesday 03 of October 2007, Havoc Pennington wrote:
> > Hi,
> >
> > On 10/3/07, Denis Washington <[email protected]> wrote:
> > > Yes, override-redirect windows are also faded in and out
> >
> > Right, what I'm asking is whether we have any precedent for *hints* on
> > these windows.
> 
>  Yes, right in the spec, since some time :). There's e.g. a short 
> section "Override-redirect windows" mentioning them.
> 
> > It's kind of a weird thing, because override redirect has always been
> > the "don't mess with my window at all" escape hatch. Metacity for
> > example won't even create an inside-WM representation for these
> > windows.
> >
> > For compositing managers, I guess if it didn't mess with your window
> > at all then the window wouldn't be drawn on the screen. But I'm
> > wondering to what extent the escape hatch still exists. Do we have in
> > the EMWH these days something like "override redirect causes the WM to
> > ignore a window for purposes of resizing, stacking, and window
> > navigation; however, override redirect has no effect on compositing
> > the window"?
> 
>  No, there's nothing like that in the spec, but it's kind of logical that a WM 
> wouldn't resize or Alt+Tab to an override-redirect window. However, in fact, 
> probably having something like that stated explicitly would be against the 
> usual spirit of X of not forbidding anything just in case one day somebody 
> comes up with a way of doing it that makes sense ;).
> 
> > Anyway - regarding the hint proposal, one suggestion is to come up
> > with a more descriptive name than AUXILIARY, such as VISUAL_EFFECT.
> > Then in defining what the WM should do with this window, spell out
> > that the CM should render the window "as is" - which is almost saying
> > "do the equivalent of override redirect for compositing, since
> > override redirect itself does not apply to compositing" - that is,
> > composite this window literally without overriding anything. I don't
> > know. Anyway, it needs to be precisely specified what you want the CM
> > to do and not do.
> 
>  I agree here. AUXILIARY sounds like A_SPECIAL_HACK. I think that ideally all 
> such effects should be in the CM, but in reality I would be fine with having 
> this VISUAL_EFFECT.

Yes, VISUAL_EFFECT is definitely a better name.

Cheers,
Denis