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



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]