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 <mgraess...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
