Current state of Window Decorations

[Carsten Haitzler (The Rasterman)]

On Thu, 25 Jun 2020 11:57:42 +1000 Brad Robinson <brobinson at toptensoftware.com>
said:

> Hey All,
> 
> What's the current state and/or plans for window decorations with Wayland?
> 
> I just stumbled on this post
> <https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/
> >, and after reading the comments I've got to say I'm quite shocked that
> getting a window to appear on screen with title bars and decorations that
> match the rest of the OS appears to be a non-trivial task.
> 
> Am I missing something? Have things changed since that post was written?

That's how it is. Correct. The point is that clients draw their own decorations
and handle events on them to initiate actions (like begin a move or resize or
close/exit etc.).

The position (for Wayland) has always been "that's the job of a toolkit and apps
will 99% of the time not know or care as the toolkit takes care of it". The
major toolkits all do take care of it and do client side decorations, so it's
a solved problem. It's necessary as there is no guarantee that a compositor will
support any server-side decorations. Unfortunately as you are making a toolkit,
this now is part of your problem-set to address.

I was initially not happy with the client side decoration position of Wayland
but I've come around and I think its definitely the better path for both
consistency (frames match the content now rather than clash), simple "every
frame is perfect" handling (otherwise you end up with complex synronization
protocols to sync rendered content of of the frame and content so they match on
every frame) and efficiency (you can get more screen content to live in
hardware layers to have zero-copy/composite updates of application content,
given that hardware layers are often a scarce resource).

I don't think there is much point in the "have decorations match" line of
thought because move a few pixels further into the app and the content is not
going to match anyway, unless you spend a lot of effort trying to match.
Given the fragmented state of toolkits anyway there is fairly little point, so
I would take the direction of "extend your view of the toolkit to also
design/define the titlebar and other border elements, shadows etc. and ensure
all of that can have a consistent matching look with the content of the window
with some simpler external control points to do things like perhaps select a
base and hilight etc. color if possible so you can later color-match at least".

-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
Carsten Haitzler - raster at rasterman.com