[q66]

lack of server-side decorations in mutter is primarily a technical problem that's not really easily solvable - currently the compositor code does not actually depend on any drawing library, to draw native serverside decorations it'd have to pull in entire gtk (a lot of effort was put into eliminating gtk from the wayland compositor path in the first place; mutter the X11 window manager, i.e. what xwayland applications use, has the dependency, so it can draw decorations)

serverside decorations are generally a broken paradigm too, pretty much no other system than X11 does them, and they introduce limitations and inconsistency to the application UI (the application can't reasonably control their contents so they're there to provide 3 buttons and waste a bunch of space), having integrated clientside decorations is one of the more visible reasons why gnome's UI feels polished and consistent

if the application is incapable of drawing reasonable decorations on its own, there is now libdecor (e.g. SDL uses it) and it has gained a gtk backend a while back, so it should be able to draw native decorations; while applications using a full toolkit have no problem in the first place, because the toolkits are fully capable of it

[jchw]

Full stop and without prejudice, libdecor is a bad idea. It requires linking to C code which is not normally necessary on Linux, and if you want to respect the GTK theme in GNOME, you need to link to GTK (even if indirectly: it still has to be in your process's address space) and have access to user settings. This is a whole lot of complexity that GUI libraries and container runtimes will need to deal with just for GNOME if they want something as ridiculous as native looking titlebars, especially considering a wide variety of applications that otherwise don't care about looking native would definitely like to have native titlebars. Another good example of a situation where it'd be nice is Wine, which can currently have native titlebars on X11 but not Wayland.

> lack of server-side decorations in mutter is primarily a technical problem that's not really easily solvable - currently the compositor code does not actually depend on any drawing library, to draw native serverside decorations it'd have to pull in entire gtk (a lot of effort was put into eliminating gtk from the wayland compositor path in the first place; mutter the X11 window manager, i.e. what xwayland applications use, has the dependency, so it can draw decorations)

Application developers and users don't care about Mutter's clean dependencies. It doesn't matter how the problem is solved, it just matters that it is solved. For all the application developers care, they can resolve the problem by having another process manage GTK shells around applications and not having Mutter actually do it.

As for not wanting GTK in Mutter, well, a lot of applications also don't want to have GTK in their process space, so it seems like this desire shouldn't be very surprising to GNOME developers.

What will happen here is that libdecor will be treated like a polyfill just for the snowflake case of GNOME and the damn-near rest of the world will figure out a way to do SSD. Exactly how doesn't matter, so as long as it's out of the application's own concerns. This is basically the only way that things can work, because if you wanted e.g. native titlebar regardless of whether you were on GNOME or KDE or something else entirely, you don't want to have every single flatpak/snap/whatever needing to pull in the entirety of GTK4 and Qt6 or whatever just to be able to try to have native titlebars. The only reason this works for GNOME is that GNOME is the only DE that does things that only work if they are the center of the universe, so you can have the GNOME case and the rest of the world case just fine. (I know the common argument here is "but what about Weston", but I am not aware of any desktop Linux system that boots into Weston, so it's really neither here nor there.)