Current state of Window Decorations

[Brad Robinson]

Thanks Simon/Pekka,

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?

That said, what would be the recommended way to implement this - would you
typically have one surface for the decorations and an embedded sub-surface
for the content area?  eg: what happens if you use a drawing library
(cairo/skia whatever) for the decorations but then want to embed opengl
content for example.

Brad

On Thu, Jun 25, 2020 at 6:25 PM Pekka Paalanen <ppaalanen at gmail.com> wrote:

> On Thu, 25 Jun 2020 11:57:42 +1000
> Brad Robinson <brobinson at toptensoftware.com> wrote:
>
> > 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?
>
> Hi,
>
> I don't think you're missing much.
>
> Without specific Wayland extensions saying otherwise, clients either
> decorate themselves or live without decorations. I believe the state of
> the art is:
>
> https://gitlab.freedesktop.org/wayland/wayland-protocols/-/tree/master/unstable/xdg-decoration
>
> I wouldn't say that the fact that Wayland extensions exist for
> server-side decorations means that a Wayland client would be right to
> not implement client-side decorations. Any compositor likely does not
> implement all the extensions ever defined or even in wayland-protocols
> repository, so clients should have fallbacks. However, it is up to you
> as a developer to decide which fallbacks you implement and which you do
> not. Obviously that will affect your user experience on compositors
> where the fallback would be necessary but you didn't implement it.
>
> Unfortunately we don't have the wayland-protocols adoption website up
> yet, where you could see which compositors and toolkits support which
> extensions. Weston does not support the extension, but I would assume
> some other compositors do.
>
> There are good justifications for both client-side and server-side
> decorations. Which one is better depends on your goals and policies,
> and what you value more, which is why the question raises so much heat
> that few people like to talk about it much as it nearly always
> escalates to a flame war when more people join the discussion.
>
> For example, for some, "match the rest of the OS" is a non-goal, and
> making the app itself look consistent is a goal. For others, it's the
> opposite. Will the application always look and feel the same no matter
> in what environment you run it in, or should it change itself according
> to the environment. How do you make the user feel at home? There is a
> lot more to it than just decorations.
>
>
> Thanks,
> pq
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20200625/ac616c5c/attachment.htm>