Re: WHY: Re: Still need a hint for undecorated windows

[Tuomo Valkonen <tuomov iki fi>]

On 2005-06-24, Bill Haneman <Bill Haneman Sun COM> wrote:
> Ridiculous.
>
> Here's a GOOD REASON for this hint:
>
> * applications sometimes want/need to post windows that should not be 
> decorated, and perhaps shouldn't even be distinguished visually as 
> "separate top level windows" - examples are certain types of popups, 
> splash screens, and transient windows.

The WM can decide how to decorate these based on abstract type information.

> override-redirect.  
> The problem with override-redirect is that it 
> 'hides' the window from the WM, thus conflicting with assistive 
> technologies such as onscreen magnifiers, 

Pop-up menus grab all input, so override-redirect isn't such big an
annoyance after that. I don't know if they should also really be
managed by the WM... certainly its easier to handle them on the
app-side. 

> You may think that splash screens are evil

They are, as they currently are implemented. (Override-redirects or
otherwise annoying popups instead of just displaying it in what is
to be the app main or initial document window while it is loading..)

> , that popups should never be  toplevels, 

Dialogs should rather be implemented within the app window... Ion tries to
emulate this but isn't always succesfull without tweaking because people
don't get that toolbox windows (that are absolutely crappy UI design, btw)
are not transients. Transients are essentially modal. Or they forget to mark
things transients that are such. Acrobat reader (4.x) is the archetypal of
this: it doesn't mark dialogs transient, but when its main window gets
hidden by the WM, it hides the dialog too, and this can cause an annoying
loop in Ion. It doesn't break the ICCCM by this, but certainly does violate
all good UI design principles, i.e. letting the WM do its job instead of
trying to be its own WM.

> I don't think we can reach 
> consensus that all forms of undecorated window (in an 
> otherwise-decorated DE) are forever evil; therefore an UNDECORATED hint 
> is required (until such time as all applications which disagree with you 
>    die out).

Undecorated is not evil, if the user desires so by the choice of WM or by
request from it. The app decorating things and expecting the WM not to is.
The WM deciding to not decorate things should be based on the window type or
user's request, not the app's explicit request, because this only leads app
writers into making their own decorations and ignoring WMs that would rather
display their own decorations (because they think hints are commands). When
the hints are more abstract, at least a few more programmers would expect
different WMs to behave different, and thus make less restricting
assumptions on the environment. 

-- 
Tuomo