SDL2 Lands Support For Client-Side Decorations On Wayland

[pal666]

lol, i recall few years ago when clueless kde zealots were crying and claiming everyone will have to reimplement decorations if they are not server side, i said that such problems are solved with a library. and now we have such a library. not surprisingly, written by gnome people

[iskra32]

No it's just that SSDs go completely against the design of Wayland and that of Gnome applications. Under Wayland, clients are supposed to render themselves. In Gnome applications, the header bar is not just a title bar with close buttons. It can also contain widgets with application functionality. Do you see how it makes sense for the application to draw itself and the header bar at the same time? Only it will have knowledge of what the header bar is supposed to look like since it's no longer a generic bar thing that looks the same no matter what app you use. Conceptually, CSDs are simpler and fit better with what Gnome and Wayland are trying to do.

Wayland itself is just a protocol for sharing buffers of applications so theres no "going against the design". If a feature is desirable, Wayland compositors can be and have been extended to support it. I can definitely see where CSDs look better and provide a better experience, but I have also seen other scenarios where SSDs make the developer and user experience better. No compositor around today, even KWin, will force SSDs on you, as seen by many programs running well with CSDs on KWin. However, having the option for SSDs is good to have, such as for games and simple video players like MPV. Its far easier for the developer to just render whatever they have to and tell the compositor to decorate the window itself if the application does not have a large amount of UI elements itself. This doesn't come at any cost to user experience either, like many "ease of development" measures, given that SSDs are guaranteed 100% to look native and function well in the environment.

[pal666]

My guess is that this will just provide a border around the window that you can use to resize the window.

I don't think it will use any GTK or Qt theme that you might have.

your guess is wrong. it will use plugins for drawing which can do anything

[pal666]

He's asking for reassurance that running an SDL application under KDE will still use the KWin-provided SSDs, rather than forcibly drawing its own CSD that make it look like someone screenshotted a GNOME app and then pasted it into a KDE screenshot.

let kde provide libdecor backend which looks like kde app instead of crying

[pal666]

Gnome invented all this mess and tries to fix this with kludges.

afaik all ssd mess was invented by clueless kde people

[pal666]

I fail to understand why the GNOME devs double down on not supporting server side decorations every time.

because client side decorations are superior. you could also ask why gnome devs are developing wayland server instead of using x11 which is so dear to you

The protocol everyone but GNOME uses allows for negotation between the client and compositor as to what kind of decorations to use. A GNOME app on KWin looks identical to on Mutter, because the protocol doesn't actually force you to use the compositor's SSDs, it just allows for negotation of those capabilities.

yes, it doesn't force, it allows to negotiate. gnome says no during negotiation, but you are unhappy and you want to force gnome to do the wrong thing. try to understand that

[pal666]

I mean half the point of Wayland was that it is easily extensible compared to the mess of X extensions. And its not like the maintenance burden of SSDs is huge, they already implement them in some form for XWayland programs anyway.

lol. they also implement x11 for xwayland programs anyway, so why inventing wayland when you can just use x11?

I am trying to not just blindly hate them or jump on that bandwagon, but I just don't get what the technical issue here is.

this horse was dead more than a decade ago, but you still dont get it https://lists.freedesktop.org/archiv...ay/000988.html

[pal666]

I have also seen other scenarios where SSDs make the developer and user experience better

no, you didn't. you think it makes experience better, but you are wrong

having the option for SSDs is good to have,

no, it isn't

such as for games and simple video players like MPV. Its far easier for the developer to just render whatever they have to and tell the compositor to decorate the window itself if the application does not have a large amount of UI elements itself.

this argument holds no water. "must have ssd" does not follow from "just render whatever they have", though it follows from "i'm clueless and can't use in-process library"

This doesn't come at any cost to user experience either

it does(see link in my previous post), just some clueless people fail to understand it

SSDs are guaranteed 100% to look native and function well in the environment.

csd with proper plugin have even better guarantees. btw "native look" argument is total bullshit with respect to something which "just render whatever they have", their window content will look alien and you can't fix it no matter how many borders you draw around it

[Sonadow]

Prior to this, it worked in everything but GNOME. Now it would work with GNOME too.

No it didn't. I make weekly builds of ffmpeg and SDL2, and when I try to use ffplay to play a video, all I get is the content playing without any window border or decoration.

[King InuYasha]

No it didn't. I make weekly builds of ffmpeg and SDL2, and when I try to use ffplay to play a video, all I get is the content playing without any window border or decoration.

So you have SDL 2 built with libdecor support enabled? Because I don't know of any distributions other than Fedora that have libdecor even shipped...