Re: [EWMH] _NET_WM_WINDOW_TYPE_AUXILIARY

[Tuomo Valkonen <tuomov iki fi>]

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? 

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

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?

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

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

There's complexity in adding 1000 window types. And that's the trend.

-- 
Tuomo