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
@ColinKinloch @refi64 it is at least nice that we mostly only need to care about gnome/gtk settings here, as everyone else implements server-side decorations.
I bet things will look super messy when testing under weston... π€
I mean, should KDE apps follow KDE session settings or try to follow current desktop ones? Same for Gtk based tools, they always seem to follow their own rules even on foreigner desktops. I need to try this π
@falktx @refi64 I think the gnome namespace is more of a historical thing.
Modern things like "dark mode" are exposed via DBus with a fdo namespace from the xdg-portals.
It would be nice to get more settings via portals, it's a pain trying to figure out which dot file or gsetting has been modified when switching back and fourth between desktops.