Re: Still need a hint for undecorated windows

[Bill Haneman <Bill Haneman Sun COM>]

Lubos Lunak wrote:

> On Monday 27 of June 2005 11:31, Bradley T Hughes wrote:
>  
>
> > Havoc Pennington wrote:
> >    
> >
> > > My take would be that they _are_ intended to be complete replacements
> > > - i.e. ideally we would like to have semantic hints that cover all
> > > the reasonable cases people want to use the mwm hint, and so if a
> > > case is not covered, either it's a spec bug, or an out-there app we
> > > don't care about for the sort of relatively-mainstream scope of the
> > > spec.
> > >      
> > There is no way we could cover every possible semantic type.
> > could, the question will always be "which one do I use if I don't want
> > decorations on my window?". It's possible with the the _MOTIF_WM_HINTS
> > to turn them off; it's not using only EWMH hints. Obviously an omission :)
> >
> > <rant>
> > FWIW, we (the wm-spec-list) had this fight when writing the original
> > spec, and unforunately the idealists won. This is the reason that my
> > original implementation included the _KDE_NET_WM_WINDOW_TYPE_OVERRIDE
> > that Lubos mentioned. And as Lubos mentioned, it's only used to indicate
> > a normal window without decorations.
> >    
>
> I didn't say this. I said that I guessed it probably had been meant as 
> something like that, but that I never really got the meaning, because in the 
> end it meant anything. KWin used to have "// TODO isOverride() - what to do 
> here?" in quite some places (hell, I had that even in isSpecialWindow() which 
> was supposed to return false for standard "normal" windows and true for 
> things like TYPE_DOCK and TYPE_DESKTOP - I really didn't know).
>
> And I really hate this _KDE_NET_WM_WINDOW_TYPE_OVERRIDE thing. Instead of 
> thinking "ok, I need another panel-like window at the edge" devels just 
> though "oh, borderless ... override it is", and fullscreen wasn't "let's 
> toggle it to fullscreen state" but it was "well, fullscreen is just 
> borderless and as large as the screen anyway". Two years ago Qt/KDE support 
> for e.g. window types hint was outright pathetic, because everything can be 
> visually described using type override, stays_on_top and similar, right? And 
> I had a lot of fun when I then decided to turn KWin into something more than 
> just a stupid app painting frames around windows.
>
>  
>
> > And again, the vocal minority is 
> > winning.
> >    
>
> Minority in what way? Just wondering.
>
>  
>
> > It's rather frustrating to get replies that basically (very 
> > rudely) say: app authors are stupid and window manager authors know
> > better. Please people, is it so hard to give people what they are asking
> > for?
> >    
>
> Yes, if the people will use it for shooting at you. I'll be rude, but let's 
> face it, app authors are stupid. Ok, not really stupid, rather clueless 
> (since, I admit it, this WM stuff is not exactly trivial to graps), and not 
> all of them, but enough. More then enough to hopelessly outnumber us. If you 
> really want to give them what they want, let's scratch all this WM stuff and 
> let the app devels handle it all, since that's what they want. We won't have 
> window tabs, splits and whatever, but people will get what they want.
>
>  
>
> > How about some cooperation instead of arrogance? 
> > </rant>
> >
> >    
> >
> > > > I've had a few cases now of people wanting to be netwm-compliant in
> > > > their toolkits asking what the "correct" way to get an undecorated
> > > > window is.
> > > >        
> > > I think the answer is 1) either fix your app or report a wm-spec bug,
> > > and 2) use MWM hint while you're waiting.
> > >      
> > There is no way to fix the app. It's simply not possible to do, since
> > the spec explicitly omits the possibility. The only option is 2 (and
> > given the general attitude on this list, we'll have to live with it,
> > since it's not going to change).
> >    
>
> Nobody has still said any good reason why we'd need a noborder hint. WINE - 
> ok, that's legacy. XMMS - that's legacy. Using the MWM legacy for this legacy 
> is fine.
>  
I think my reasons were quite sound; applications can and will (despite 
what you may think they should do) pop up windows that they don't want 
decorated.  For accessibility reasons it is vital that such windows not 
be override-redirect.

Bill