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.
@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?
@falktx
hmm yeah that file is a lot bigger than I remember of, idk why exactly, maybe a side effect of libdecor trying to be really flexible wrt how the app manages the window?
> is finding the default titlebar height and the left-shadow-position offset
for the first thing, the easiest reference I know of would be Electron's CSD, which in turn was based on Chromium's but is a fair bit shorter https://github.com/electron/electron/blob/624d0856324c20699ae0f3a60a2a34d1cc2bc8a1/shell/browser/ui/views/client_frame_view_linux.cc esp GetTitlebarBounds. not entirely sure about left-shadow-position.
@refi64 thanks, that link is helpful!
@refi64 I went down to chromium code that calls directly into gtk and well, it's not pretty...
https://chromium.googlesource.com/chromium/src/+/lkgr/ui/gtk/window_frame_provider_gtk.cc#233
so they render an empty window "offline" to then try to find the bounds through the rendered bitmap, detecting pixels and whatnot.
this is insane, right?
@falktx I understand there were/are some technical obstacles in Mutter to implementing server-side decorations, but... still, the consequence of not doing it is ridiculous.