Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

[Lubos Lunak <l lunak suse cz>]

On Thursday 18 of October 2007, Tuomo Valkonen wrote:
> On 2007-10-18, Lubos Lunak <l lunak suse cz> wrote:
> >  This "arbitrarily messed with", just to make it clear, just means that
> > they will be composited on the screen,
>
> It doesn't mean that. For example, a viewing transformation transformation
> that affects the whole display wouldn't be arbitrary messing. But something
> that specifically distorts that window, is. Consider e.g. further
> transparency added to some already pseudo-transparent hack.
>
> >  No. My guess is that because it's in fact you who has tunnel vision and
> > little regard for alternatives. Since you apparently don't know, let me
> > tell you that the EWMH provides additional hints to the ICCCM and does
> > not impose too much policy by making pretty much all of them optional.
>
> Such as the multi-parent transient brain damage? Such as requiring all apps
> to use EWMH to not have their override-redirects arbirarily messed with?

 I don't know what the first is supposed to be and there's no requiring in the 
latter - first of all that's not in the spec as of now and second there won't 
be any "you have to mess with windows" in the spec. There may be "you may 
mess", but I thought you were for being abstract and non-restricting.

> Policy is also imposed indirectly by applications expecting the WM to
> support the highly-specific EWMH shit and failing without it. Alternatives
> are forgotten by making the hints too specific, when a more abstract hint
> would suffice and foster more cooperation. The struts mechanism is actually
> an example of an application managing its own windows. There's no good way
> to map the EWMH workspace model to Ion, where full screen client windows
> are sort of pseudo-workspaces. (Either you tell they're normal workspaces,
> in which case programs can get confused and the "should" part of
> _NET_WM_DESKTOP being set can not be honoured -- there are far too many
> SHOULDs and MUSTs in the spec, making it impossible to adhere to it -- or
> you create a single FS workspace, in which case switching isn't available
> from pagers. Ion also supports nested workspaces. A more abstract and
> dynamic system of "locations" and "targets" (subset of locations) with a
> "goto" request might work.)

 Fortunately, then you came and without useless complaining or calling people 
names you calmly explained the problems, suggested solutions and eventually 
saved the day. Oh, wait. Well, maybe next time.

> Then there's of course the general UTF-8 monoculturism, but at least in
> this case Xlib does the conversions from the abstract application internal
> encoding (locale or wchar_t), unlike in many other FDO and other recent
> FOSS crap, where the API and everything is UTF-8 monoculturist.
>
> >  I personally prefer hints that say what the window is and not what the
> > window is not. AUXILIARY means anything and nothing.
>
> Then think of a better name. How about OVERRIDE_REDIRECT?

 That's just asking for confusion and it doesn't say anything. In your ideal 
world where all apps would support and set all hints not having any type 
would be the perfect solution for this perfect world. But since some apps 
won't or there perhaps will come new window types, apps not having the 
exactly right type should be handled somehow by compositing managers, and I 
think at least some will take their chances that treating such windows as 
others will overall have a better result than ignoring them. That's why I 
find EFFECT to be a good way to reduce the cases when they'll have to guess.

> >> Can you think of any actually useful case where it should know that it's
> >> dealing with an EFFECT specifically?
> >
> >  Can you think of any actually useful case where some non-effect window
> > would need exactly the same handling?
>
> Consider e.g. that pseudo-transparency (or other such) hack with an OSD
> in it. Is that an "effect"?

 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.

> >  There's no complexity in adding one more window type.
>
> There's complexity in adding 1000 window types. And that's the trend.

 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.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l lunak suse cz , l lunak kde org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz