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

[Bill Haneman <Bill Haneman Sun COM>]

Tuomo Valkonen wrote:

> 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.
>  
There aren't enought types to do this.  And I don't think the type 
system was designed to handle that level of fine control, e.g. we don't 
want 15 different types.

> > 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, 
Which they SHOULD NOT DO (again, for accessibility reasons).

> 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 app requesting that a toplevel not be decorated is NOT INHERENTLY 
EVIL, you seem to selectively take use cases where the app tries to "do 
its own decoration" for the primary app window.  But that's not the only 
use case, or even the most important or common one.  The problem is that 
users almost never will want NOTHING to be decorated, that is a corner 
case.  The more realistic cases for 'desktop' class devices at least, 
are cases where some windows need to be excluded from decoration.  The 
current semantics don't accommodate all of the reasonable cases (without 
resorting to override-redirect).

> The WM deciding to not decorate things should be based on the window type
Then we need more types, perhaps TYPE_POPUP in addition to TYPE_SPLASH.

I think at the end of the day there is ample evidence that applications 
need a "dont change the visuals" hint however because we cannot 
anticipate all of the window "types" which may need this behavior.  It's 
the simplest - and I think the cleanest - solution to the problem.  You 
gotta leave some things to the applications, and trust that at least 
some application writers will get it right.

Bill

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