I mean, the app can request the compositor to have "server-side decorations" but this is treated as optional protocol.
See https://wayland.app/protocols/xdg-decoration-unstable-v1

It is implemented on all major desktops except Gnome 😭

So now all apps need to implement their own decoration, user resizing, etc feels very backwards and wasteful.

The way some compositors implement some features and some not is a bit annoying, but the main features are well supported overall.

Now to get DPF to support wayland... 😁

2 / 2

@falktx
fwiw a lot of things (e.g. SDL) just use https://gitlab.freedesktop.org/libdecor/libdecor/ for CSD

@refi64 err, my usecase is for audio plugins, which need to be self-contained.
This means each individual binary will have to contain its own copy of the entire libdecor..? 🤦‍♂️

Also libdecor also incorrectly assumes the buttons to be always on the right side 😔

Anyhow since my target is audio plugin UIs and they are mostly going to be embed in a host view, a super minimal hack for standalone windows using gtk and subsurfaces is quite ok with me, and that one gets the buttons correct

@falktx
it's not super big...but it's also kinda based around a dynamic plugin system which I COMPLETELY FORGOT so it's probably not trivially usable in a static context anyway, oops 😅

(though I guess if nothing else, the GTK backend might be useful for reference purposes? but perhaps not if you already did most of the work anyway)

@refi64 the gtk backend seems useful yes, but also over-complicated? why is it manually drawing things when gtk has ways to render a titlebar for us?

the only thing I need right now is finding the default titlebar height and the left-shadow-position offset. there are ways to find this info without drawing everything manually right? ...right?