On Thursday 20 February 2014 11:49:05 Jasper St. Pierre wrote:
I guess I'm curious then, what's the goal? What does this provide beyond the Motif hint?
I think the problems with Motif hint should be obvious: what does this mean? _MOTIF_WM_HINTS(_MOTIF_WM_HINTS) = 0x2, 0x3, 0x0, 0x0, 0x0 compare that to: _NET_WM_STATE(ATOM) = _NET_WM_STATE_UNDECORATED I at least have no idea what the motif hints want to tell me and I honestly don't understand what the KWin code does to parse it. This results in it being one of the last parts of Xlib code usage in KWin due to the fact that I do not dare to touch it. This results in broken code and as I outlined in the first mail to this thread it is causing issues like toolkits using splash window type to indicate a frameless (note: not CSD) window. This shows me that we are lacking an important feature in the spec. I had not been around when the spec was first created but after all I was told one of the objectives was to have a good replacement for motif hints. One of my objectives for our KWin/5 release is to drop the Motif hint support due to the issues it is causing. I wanted to make sure that non-Qt applications will still function with KWin (Qt uses a KWin-specific hint to request no decoration). If replacing a Motif hint is not needed, that's fine with me and I withdraw the proposal. I think the addition is an improvement over the current state. It might not solve the CSD styling question, but I think that's a topic for another thread and should be solved by those who are interested in CSD. Also I think that undecorated and CSD are two different topics. In KDE we have lots of undecorated windows in the desktop shell but none of them is using CSD. I don't see why that should be mixed. Cheers Martin
If it's "nothing, it's just standardizing it", then I'm against it. CSD requires a complete solution, and I'd rather see a complete solution standardized than a slightly-less-bad Motif hint. I could add support in mutter for the new state, but I wouldn't port GTK+ to it. The Motif hint has wider reach across a wide pool of existing WMs, and we'd just be regressing for no real gain. Not to mention that on WMs without support for client-set frame extents, we keep the "border" hint on so that users can resize the window through the WM-provided borders, even if they don't get a server-side titlebar. On Thu, Feb 20, 2014 at 11:38 AM, Martin Graesslin
<mgraesslin kde org>wrote:
On Thursday 20 February 2014 10:23:41 Jasper St. Pierre wrote:There's a bunch of open questions about this state. If a window is CSD-drawn, does it include drop-shadows, or should the compositor draw drop-shadows?thanks for the feedback. I think there is a small misunderstanding in what I wanted to achieve with the proposal. It's not to come up with the ultimate way to handle CSD - I think it's obvious that I'm the wrong person to propose that ;-) The idea is really just to make a modern way for the motif hint. Whether or how CSD styling is done is IMHO completely orthogonal. Especially the consideration of shadows is something which has nothing to do with whether the window is decorated or not. The hint to not decorate the window is clearly relevant for the window manager and the styling is clearly relevant to the compositor. Thus it addresses two completely different parts and should IMHO not be mixed. Cheers Martin _______________________________________________ wm-spec-list mailing list wm-spec-list gnome org https://mail.gnome.org/mailman/listinfo/wm-spec-list
Attachment:
signature.asc
Description: This is a digitally signed message part.