Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

[Lubos Lunak <l lunak suse cz>]

On Tuesday 16 of October 2007, Tuomo Valkonen wrote:
> On 2007-10-16, Lubos Lunak <l lunak suse cz> wrote:
> >  I did, but maybe I didn't get it. Are you talking maybe about "crappy
> > toolkits or such forcing a window type being specified"? AFAIK it's a
> > rather common practice to detect client support for the spec by a
> > presence of any _NET_WM_WINDOW_TYPE hint.
>
> We're talking about __override-redirect__ windows here. It's rather
> common for them to have no hints. Why should programs specifically
> support EWMH to not have their override-redirect windows arbitrarily
> messed with?

 This "arbitrarily messed with", just to make it clear, just means that they 
will be composited on the screen, which they will be anyway, since otherwise 
they wouldn't be visible at all with a compositing manager running. Which 
means those programs won't see any difference, since nothing will happen with 
those windows as such, only possibly with their appearance. I don't see how a 
fact that some window will get faded in means end of the world for the 
application or something.

> Why should they support it at all? It's largely highly 
> WIMPshit-specific crap designed by people with a tunnel vision and
> little regard for abstraction and alternatives.

 Thank you for your kind words.

> The ICCCM, by contrast, mostly provides basic "how can we get along without
> imposing too much policy" guidelines. If the EWMH or other FDO crap goes
> against the spirit of the ICCCM, instead of simply providing additional
> _hints_, why should one choose it over the former or an interpretation
> thereof? Because the desktop herd that is the source of present sordid state
> of *nix/FOS wants that?

 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.

> I also mentioned that AUXILIARY is a better more abstract hint to
> override crap that wants to set the TYPE hint on override-redirects,
> than the highly-specific EFFECT. Why should the CM or WM care what
> is contained in an override-redirect that it doesn't know how to
> handle in a special manner, unlike e.g. menus?

 I personally prefer hints that say what the window is and not what the window 
is not. AUXILIARY means anything and nothing.

> 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?

> And isn't that likely to be a very 
> marginal class? Wasn't even the original post about some very ugly
> overlay hack or something? (Can't be arsed to find it now.)
> Let's keep the complexity down if it achieves little.

 There's no complexity in adding one more window type.

> But do whatever you will. I've lost all hope in FOSS and am likely
> to switch to Windows once it comes time to upgrade.

-- 
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