Current state of Window Decorations

[Daniel Stone]

Hi,

On Thu, 25 Jun 2020 at 10:01, Brad Robinson
<brobinson at toptensoftware.com> wrote:
> As a toolkit developer coming from Windows/OSX this is fairly shocking.  I'm aware of the decoration protocol, but given it's not supported (and by the sound of it never will be) on some of the major distros makes it almost worthless.
>
> Seems odd to offload this responsibility to every toolkit without providing a mechanism to achieve any consistency.  Or... is this just my background in Windows/OSX where consistency in these areas is really encouraged and this just isn't expected on Linux?

Others have said this well, but the big difference is that Windows and
OS X both have complete native toolkits as part of their base
platform. Those toolkits implement widgets, things like titlebars,
IPC, intra-process message handling and signaling,
internationalisation, application lifecycle management, etc etc.
That's not something we have: toolkits are instead an optional and
interchangeable component.

If you use one of the major extant toolkits, then you can reuse all
that functionality. This is why even some of the monoliths like
Chromium reuse toolkits. If you want to create your own toolkit from
scratch and not base on one of the existing ones, then for better or
worse, you get to recreate all the functionality they provide.

Shifting responsibility for window decorations to the compositor
doesn't solve the problem. Yes the compositor would render them for
you, but then you have additional protocols (with all the
synchronisation issues that implies) for the client and compositor to
co-ordinate rendering of the decorations and the content.

Neither is objectively better or worse, it's just a different design
which inherently brings different tradeoffs.

Cheers,
Daniel