Re: Still need a hint for undecorated windows

[Lubos Lunak <l lunak suse cz>]

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.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l lunak suse cz , l lunak kde org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/