Re: Still need a hint for undecorated windows

[Carsten Haitzler (The Rasterman) <raster rasterman com>]

On Mon, 27 Jun 2005 11:31:04 +0200 Bradley T Hughes <bhughes trolltech com>
babbled:

> <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. And again, the vocal minority is
> winning. 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? How about some cooperation instead of arrogance?
> </rant>

hey - this is just a spec a "piece of paper". :) i guarantee that there are wm
authors who dont take that same high "horse attitude" and will work with toolkit
makers - separately as a gentlemans agreement if anything. it wont be a formal
spec but at least u know that N% more users will have things work as that wm's
userbase then gets a working set of apps etc. i personally would like to see
this be a 2 way street. it shouldn't just be wm authors going "here is the spec.
this is what you get. take it or leave it". there should be things going the
other way too - so if toolkit authors have an issue and need it solved and it is
BEST solved outside the toolkit (ie in the wm) then there should be constructive
dialogue to solve it. it may mean the solution ends up split between toolkit and
wm, or entirely in the wm or entirely toolkit after some discussion - maybe wm
authors will resist writign a tonne of complex intricate code just to make some
obscure toolkit request happen. i can see why - but if its relatively simple and
easy to do - i see little reason for resistance.

IMHO as long as the toolkit "stays in its window" i think its fine. the moment
it starts scribbling on top of other windows, the root window or places outside
its inner client window - it's within its right to do whatever it likes. this
forum should be a place to enable things, not veto things. :)

anyway - don't worry - you will get support from authors in places. you do have
allies who are also pragmatists :) anyway - i can guarantee that e 0.16.x and
0.17 and on will honor the mwm hints as absolute overrides form any netwm
semantic hints when it comes to decoration, of course a users settings (saying
"this window MUST use this border and screw what the app says" will ALWAYS take
top priority imho). this method will work semantically with backward
compatibility as if the app is using mwm hints for older wm's to say "no borders
thanks" any new netwm hints are likely trying to imply the same, or similar
decorations.

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

so is mwm hints good enough a solution for you? its definitely the path of least
resistance imho? i will be happy to support any netwm "borderless deco" hints
should they appear too.

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com
裸好多                              raster deephackmode org
Tokyo, Japan (東京 日本)