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

[Bill Haneman <Bill Haneman Sun COM>]

Lubos Lunak wrote:

> On Friday 24 of June 2005 13:30, Bill Haneman wrote:
>  
>
> > Tuomo Valkonen wrote:
> >    
> >
> > > On 2005-06-24, Carsten Haitzler <raster rasterman com> wrote:
> > >      
> > >
> > > > On Fri, 24 Jun 2005 11:54:54 +0200 Lubos Lunak <l lunak suse cz> babbled:
> > > >        
> > > >
> > > > > I yet to have actually see somebody saying a single reason why this is
> > > > > really
> > > > >          
> > > > application developers want it
> > > >        
> > > Because they mistakenly think they know better than the user or the wm
> > > maker how UIs should work, not because they have any real reason for it.
> > > This kind of thinking only eventually leads to the loss of such a
> > > blessing as a separate window manager, and thus to absolute unusability.
> > >      
> > 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.
> >    
>
> _NET_WM_WINDOW_TYPE_SPLASH. No idea what exactly you mean with popups and 
> transient windows in this case.
>
>  
>
> > The usual way to deal with this problem is to either use WM_TYPE_DOCK,
> > which is semantically inaccurate,
> >    
>
> This may be the usual, but, as you point out yourself, incorrect way.
>
>  
>
> > or (more commonly) to use 
> > 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, onscreen keyboards, and
> > defeating other WM functions.
> >
> > I agree that the WM is a "blessing", e.g. a Good Thing.  It does lots of
> > things for us _besides_ just adding decorations and drag handles.  Why
> > should we have to defeat all of the positive functionality of a WM in
> > order to get undecorated windows (or else abuse WM_DOCK) ?
> >
> > You may think that splash screens are evil, that popups should never be
> > toplevels, yadda yadda, but this hardly matters.  Although the WM spec
> > *should* set some degree of policy and encourage "good UI design", it is
> > really hopeless to think that wm-spec-list is an appropriate universal
> > arbitrator of what is good and bad.  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).
> >
> > The accessibility issue is a strong practical reason (as opposed to just
> > a philosophical one) why the hint is better than just requiring such
> > apps to use override-redirect or DOCK.
> >    
>
> At least your conclusions are flawed. 
I think you misunderstand me.

> You basically argue that since current 
> hacks and workarounds don't quite work, we need better hacks and workarounds. 
> The proper way of handling splash screen is the window type, which we've 
> already had since some time. I don't know what you mean with the other 
> windows, but if e.g. onscreen keyboards/magnifiers are too different they can 
> get their own WM type as well
They need this, but my comment is not about OSKs and magnifier's own 
windows; the problem is that override-redirect windows, when used by 
other applications, break OSK and magnifier functionality by avoiding 
the WM.  So it is very important to make it possible for applications to 
use override-redirect less.

We need to encourage apps to allow more things to be managed by the WM.  
That means allowing the application to have a little more control say 
about what the WM does with some of those windows.  I agree the this 
should be a semantic hint rather than an "I want to draw my own UI".  
Personally I am less interested in "applications that want to draw their 
own borders" in general - I sympathize with the POV that says that this 
is bad app behavior.  But not all toplevel windows are "the same", and 
currently the WM type/hint vocabulary is not quite sufficient.

> that could also imply no border if needed 
> (although I don't quite see why - I use KMag normally with borders - I'm not 
> accessibility user though). I still don't see why we should encourage 
> "random" noborder windows just for the fun of it. And if we officially add a 
> hint to the spec it will encourage it and we'll see more xmms-like apps.
>  
I really don't agree; application writers will hack as necessary to "see 
what they want" on their favorite platform.  I don't think that we would 
be opening the floodgates to bad style by adding a 'Don't decorate' hint 
- as has been pointed out, apps already do this via either hackish means 
or with MWM hints.

> BTW, for those of you who don't know, Tuomo is a(the?) developer of the Ion 
> window manager. Given how Ion is different from our "traditional" WMs he's 
> probably seen more abuse from the apps then we all together.
>  
Bill