Bug 172028

First of all, there is no need for any of this. Window decorations are a WM feature and it's primarily up to the WM to handle them. If you want a window without borders, just disable them (Alt+F3/Advanced or set up a shortcut). If you want this handled automatically, you can set up window rules for that (Alt+F3/Advanced as well), you can even affect only a subset of such windows if you set a different window classname using the -name argument for the app.

As for the actual "bug", it is very clearly a urxvt problem. Making a window override-redirect, thus effectively disabling WM's control over it, and then not liking the fact that the WM does not handle it, is confused (and I'm not taking any "low quality window manager" rubbish from somebody who thinks override-redirect is a good excuse for a borderless terminal). Speaking of protocols and hacks, even just blindly setting the no-border hint and possibly failing is better, as that's at least more in line with the ICCCM, which says applications usually should not take anything for granted from the WM. Just imagine you use a WM that has absolutely no support for Motif.

And, finally, KWin does not implement Motif hints, as they are generally considered to be ill-designed, so only a very small subset is supported for backwards compatibility (to quote from the sources, itself taken from elsewhere, "We support those MWM hints deemed non-stupid"). As you've already found out yourself, it does not even seem possible to find a good documentation on them, so I wouldn't know what to do and how, even if I wanted to. It seems much safer to leave it as it is than risk announcing something wrong and possibly breaking much more than would be fixed by this, but in case you find those docs, I might reconsider. I'd also like to point out that in the (not very clear) docs I could find it appears to be nowhere said that _MOTIF_WM_INFO would be a requirement for _MOTIF_WM_HINTS.

(In reply to comment #1)
> First of all, there is no need for any of this. Window decorations are a WM
> feature and it's primarily up to the WM to handle them.

I finally lerned so as well, and have my own system configured accordingly. But I would believe that most users would rather like to control all aspects of their terminal windows, including their decorations, from one single X resource file, and not in separate places. So there might be a certain point in having apps requesting certain decorations, in response to such configurations.

> As for the actual "bug", it is very clearly a urxvt problem. Making a window
> override-redirect, thus effectively disabling WM's control over it, and then
> not liking the fact that the WM does not handle it, is confused.

There might be a misunderstanding here: the window does only override-redirect to give a borderless window when requested and the window manager doesn't cooperate well enough. So override-redirect wouldn't be used if _MOTIF_WM_INFO was detected. In that case, the WM would keep in control, and a hint be used.

> Speaking of
> protocols and hacks, even just blindly setting the no-border hint and possibly
> failing is better, as that's at least more in line with the ICCCM, which says
> applications usually should not take anything for granted from the WM. Just
> imagine you use a WM that has absolutely no support for Motif.

I see a contradiction in this paragraph. I personally would agree with the first half, set the hint blindly and hope for the best. My patch against urxvt to this effect was rejected, though.

The urxvt developer seems to use the second half as an argument: expect nothing from the wm unless advertised, and use extreme measures (i.e. override-redirect) to get borderless windows (as requested by the user) even in the presence of window managers with no motif support at all.

It boils down to what you consider worse, either an override-redirect window when none would be required, or a window with border when the user requested a borderless one. I guess there are arguments for both sides.

> And, finally, KWin does not implement Motif hints, as they are generally
> considered to be ill-designed, so only a very small subset is supported for
> backwards compatibility

I see. In that case, I can agree with you verdict of WONTFIX.

Just for the record, there was something strange about the Xfwm4 "fix", and indeed looking at the bugreport there, it is just a workaround that in practice does not do anything other than triggering the rxvt-unicode check. Looking at the gentoo bugreport where you pasted the code with the check confirms that it's broken.

So I've added the same workaround to KWin, it will prevent rxvt-unicode from the deliberate usage of override-redirect but will not do anything with proper applications (all Motif applications, for example), and this specific no-border hint is already among the few MWM hints found worth supporting in KWin. After looking at OpenMotif sources I'm by now also quite confident that properly announcing _MOTIF_WM_INFO in KWin or any other window manager that does not closely mimick MWM would be wrong, so I hope that doing this nothing in KWin helps it to ascend from the mud of low quality window managers ;).

(In reply to comment #3)
> So I've added the same workaround to KWin, it will prevent rxvt-unicode from
> the deliberate usage of override-redirect

I can confirm that the fix from http://websvn.kde.org/?view=rev&revision=867241 works in my kwin 3.5.10. Will you include it into the 3.5 branch as well?
I think you might as well change the resolution to FIXED once that is released.

> but will not do anything with proper applications (all Motif applications,
> for example), and this specific no-border hint is already among the few MWM
> hints found worth supporting in KWin. After looking at OpenMotif sources I'm
> by now also quite confident that properly announcing _MOTIF_WM_INFO in KWin
> or any other window manager that does not closely mimick MWM would be wrong,
> so I hope that doing this nothing in KWin helps it to ascend from the mud of
> low quality window managers ;).

Just for clarification, did I understand you correctly that there is a difference between "properly announcing _MOTIF_WM_INFO", which you did not do, as KWin isn't an MWM clone, and simply providing this fake atom, as you did in the fix, to keep rxvt-unicode happy?

I've added the change to 3.5 branch as well, since that's certainly simpler than arguing about it, but I won't change the resolution, as I don't consider anything "fixed". As for the last question, yes.