On Thu, 20 Feb 2014 18:47:14 +0100 Martin Graesslin <mgraess...@kde.org> said:
> 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 long ago in a land far far away... when i was young ... i actually spent some time reading some documentation... other than my own code. and this resulted in this code appearing so i never needed to read those docs again: https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_x/xlib/ecore_x_mwm.c#n35 https://git.enlightenment.org/core/efl.git/tree/src/lib/ecore_x/Ecore_X.h#n1650 those fields mean something. they have values. i worked out what they meant. at least most of the ones i cared about. it's pretty simple - like a lot of other xlib stuff... like xchangewindowattributes()... its a bitfield set of flags telling you which other fields have relevant data, then those have relevant values. you shall never have to say "i have no idea" again. :) > 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. if a splash is or is not frameless is up to the wm to decide. it's not guaranteed one way or another. mwm hints on the other hand are very explicit in what the client is asking for. > 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). not to be too harsh... dropping mwm because "you don't understand it" and then proposing everyone rev their toolkits and code for a new spec for the same reason is not a good reason to do this. sorry. :( for someone that has been around the window manager block a few times... this is folly to do this. spend some quality time reading up some documentation, sample code, other wm or toolkit code and figure it out. i spent that time many years back and encoded it into a library layer that both the wm and toolkit share and then didn't need to care again. if i ever wanted to know the details a quick few seconds of excursion into the code would tell me. > 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. it introduces more complexity. now app shave to set BOTH mwm AND this new hint (because kwin will drop and break mwm hint support). now we have 2 hints where one says "borderless or not" and the other says "i want to specify a whole range of flags, where i can specify not just frame or not but title, resize handles and much more, as well as specify input mode, and desired functionality"... and what if these 2 hints conflict? how do we mix and match results? my suggestions above. :) back to release mode. :) > 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 -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org https://mail.gnome.org/mailman/listinfo/wm-spec-list
