GNOME.org
 

Re: Proposal: Add a window state for "undecorated" windows

On Thu, 20 Feb 2014 18:47:14 +0100 Martin Graesslin <mgraesslin 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 

<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



-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster rasterman com
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]