Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

[Tuomo Valkonen <tuomov iki fi>]

On 2007-10-18, Lubos Lunak <l lunak suse cz> wrote:
>  I was going to admit that EFFECT perhaps is not the best name, but after some 
> more thinking, I actually think it fits, semantically. Since the description 
> of the type would be something like "the compositing manager should not apply 
> any effects to this window as it relies on its exact presentation", then I 
> can think only of windows used for effects to rely on being shown exactly the 
> way their are. I actually personally don't see a reason why an OSD should not 
> get a fade-in effect. I can't think of anything that definitely should not 
> get effects except for effects.

I don't consider OSD an effect. An effect is something superfluous,
whereas an OSD can contain very useful information. How about OVERLAY
(for overlaid information)? 

The OSD program may also itself be doing fade in effects. In fact, 
maybe the CM trying to use window types to decide on effects for 
override-redirects is misguided, and it should simply be requested
by some general classes of effects to provide them? ("in" => fade in,
"out" => fade out, "substance" => shadow, etc.) Or perhaps
a HAS_SUBSTANCE hint alone? INSUBSTANTIAL as the window type?
Whatever.

>  Somewhat unrelated, I plan to do a logout effect in KWin that would be 
> triggered by having a special window type set on the logout window dialog 
> from the session manager and would fade everything except for this window. If 
> one more type for this is bad, what would you suggest as a good way? Just 
> curious.

That's actually something like a SYSTEM_MODAL window, and since there's
a MODAL state^1 already, it should probably be another state. Or perhaps
some interpretation of the modal state, when there's no main window. 
(This would be a semantically much better hack for the setting of
transient_for property to root!) 

...

But I'm getting tired of this discussion. I've made my case, and it's
taking too much of my precious time to continue going over this shit.
Do whatever you will, it's not as if doing one thing right will fix
the clusterfuck that GNU/Linux an FOSS has become.

...

^1 I think all transients should be interpreted by the WM as modal -- 
   they're _transient_ after all -- and the rest of the dialogs in a 
   zillion-window mess should neither be modal nor marked as transients.

-- 
Tuomo