I may have worded it a little strongly (despite tempering it with the word “almost”), but hear me out.
GTK will use SSD so long as you don’t customise the title bar. I think you can even query it, with effort (gdk_wayland_display_prefers_ssd, c.f. https://gitlab.gnome.org/GNOME/gtk/-/commit/f2adaba237519642...), and thus behave differently depending on compositor preference. (But even that is mildly nerfed from the org_kde_kwin_server_decoration_manager interface, since it only exposes “prefers SSD” and not “supports SSD”—though in practice I suspect there’s no difference in any compositor.)
But guess what? GTK 4 has regressed matters in this space. Fancy that. If I run gtk3-demo, as a tiled window it gets Sway SSD and an app header bar which duplicates the title (fine), but it doesn’t have the window border or shadow (good). When I float the window, it gets border (including top radii) and shadow. This is well-behaved software, not acting quite how I’d prefer it to (I want SSD even floating, even double-title-barring), but still reasonably. But gtk4-demo? It gets border and shadow (drawing outside its designated area even in tiling mode, and I’m not sure why it’s possible for it to do that) regardless of whether it’s floating or not. Progress. They’re forging ahead with ignoring the existence of SSD as far as possible even in GTK.
I just tested running gtk3-demo and gtk4-demo in sway. gtk4-demo does draw its shadows on other windows, but I wouldn't have noticed that if you hadn't brought it to my attention. Each has only the GTK title bar (no sway title bar) in both floating and tiled mode (but not full screen), which is, imo, a reasonable way for things to work.
Not sure how you’re getting no Sway title bar out of it. In fact, when I run `swaymsg border csd` with the tiled gtk4-demo focused, I get “This window doesn't support client side decorations” and I have no idea what’s up with that, especially given that the window definitely gets border csd when floating. ¯\_(ツ)_/¯
It’s possible it’s related to more recent changes in Sway. I haven’t updated Sway since March (since I’ve been using the high-DPI XWayland patches and updating is comparatively bothersome). I dunno.
Incidentally, I mostly use tabbed layout, and you’re always going to get server-side decorations out of that, since you’re breaking out of the rectangles mould.
GTK will use SSD so long as you don’t customise the title bar. I think you can even query it, with effort (gdk_wayland_display_prefers_ssd, c.f. https://gitlab.gnome.org/GNOME/gtk/-/commit/f2adaba237519642...), and thus behave differently depending on compositor preference. (But even that is mildly nerfed from the org_kde_kwin_server_decoration_manager interface, since it only exposes “prefers SSD” and not “supports SSD”—though in practice I suspect there’s no difference in any compositor.)
But guess what? GTK 4 has regressed matters in this space. Fancy that. If I run gtk3-demo, as a tiled window it gets Sway SSD and an app header bar which duplicates the title (fine), but it doesn’t have the window border or shadow (good). When I float the window, it gets border (including top radii) and shadow. This is well-behaved software, not acting quite how I’d prefer it to (I want SSD even floating, even double-title-barring), but still reasonably. But gtk4-demo? It gets border and shadow (drawing outside its designated area even in tiling mode, and I’m not sure why it’s possible for it to do that) regardless of whether it’s floating or not. Progress. They’re forging ahead with ignoring the existence of SSD as far as possible even in GTK.