Re: Still need a hint for undecorated windows
- From: Bill Haneman <Bill Haneman Sun COM>
- To: Lubos Lunak <l lunak suse cz>
- Cc: wm-spec-list gnome org
- Subject: Re: Still need a hint for undecorated windows
- Date: Tue, 28 Jun 2005 13:05:45 +0100
Lubos Lunak wrote:
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
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
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 :)
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
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
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?
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
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
] [Thread Prev