Re: Still need a hint for undecorated windows

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]