SDL2 Lands Support For Client-Side Decorations On Wayland

[Sonadow]

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...

I am referring to before this announcement.

[krzyzowiec]

Wayland itself is just a protocol for sharing buffers of applications so theres no "going against the design".

Sure there is. The application is supposed to handle drawing itself and communicate with the compositor about changes. That is the design of the protocol. The idea that the drawing of the application is split between the compositor and the application like in the old model goes against that design. You can argue the pros and cons of both, but you can't argue that a "server" drawing part of the application doesn't go against the design of Wayland.

[ssokolow]

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

No thanks. I don't feel like going back to the bad old Windows XP days of "Something CPU-bound is monopolizing the application's main loop. Interacting with the titlebar can't be trusted to do anything if I try to move, resize, minimize, or close the window."

...but I'll welcome a KDE backend for libgnomeisamistake if it allows applications which insist on CSDs in the negotiation process to style the resulting CSDs in a more KDE-native way.

In the mean time, I'll continue my policy of replacing or patching GNOME apps to avoid having to deal with their design language. (Thank God for Flatpak Portals. So many applications like Firefox easy to trivially switch to KDE Open/Save dialogs... still need to find/write a Qt version of Flatseal though. The damn thing feels like a badly designed tablet app and I don't feel like using the flatpak CLI for that particular task.)

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

Correction: Mutter's internal architecture is such a mistake that the GNOME developers make excuses for being unwilling to implement Wayland SSD in order to shift the blame elsewhere and convince people that the old tale about the young and the old buddhist monk ("If only we could cover the world in leather, our feet wouldn't get hurt" Old monk gives the young monk some shoes.) is mistaken.

[King InuYasha]

I am referring to before this announcement.

Ahh, okay. I was confused. Sorry!

[ssokolow]

No compositor around today, even KWin, will force SSDs on you, as seen by many programs running well with CSDs on KWin.

While it's not "forcing it on you", last I heard, the developer of Arcan was annoyed enough with GNOME to have implemented support for cropping out a GNOME window's header-bar and hiding it behind a toggle-button in the SSD titlebar in order to force the issue.

[King InuYasha]

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

The libdecor library passes through to the Wayland xdg-decoration protocol if the running compositor declares support for it. So on KDE Plasma, libdecor will pass through applications to kwin to render server side decorations.

[tomas]

ssokolow

"developer of Arcan was annoyed enough with GNOME to have implemented support for cropping out a GNOME window's header-bar...."

And there was much rejoicing among the 2 users of Arcan.. .. 😊

[pal666]

No thanks. I don't feel like going back to the bad old Windows XP days of "Something CPU-bound is monopolizing the application's main loop. Interacting with the titlebar can't be trusted to do anything if I try to move, resize, minimize, or close the window."

lol, if you can't do it properly, wait for someone else to do it for you

...but I'll welcome a KDE backend for libgnomeisamistake if it allows applications which insist on CSDs in the negotiation process to style the resulting CSDs in a more KDE-native way.

negotiation is also optional. wayland native app will just draw csd without negotiation.

In the mean time, I'll continue my policy of replacing or patching GNOME apps to avoid having to deal with their design language.

keep us posted

Correction: Mutter's internal architecture is such a mistake that the GNOME developers make excuses for being unwilling to implement Wayland SSD in order to shift the blame elsewhere and convince people that the old tale about the young and the old buddhist monk ("If only we could cover the world in leather, our feet wouldn't get hurt" Old monk gives the young monk some shoes.) is mistaken.

lol that were legends of butthurt kde imbeciles. weston doesn't have mutter's architecture and doesn't do ssd shit, which is needed only for braindead people

[oiaohm]

While it's not "forcing it on you", last I heard, the developer of Arcan was annoyed enough with GNOME to have implemented support for cropping out a GNOME window's header-bar and hiding it behind a toggle-button in the SSD titlebar in order to force the issue.

The reality here under X11 applications could decide to go CSD as well. This is common with xmms remember. Yes SSD at times under X11 does result in applications having two windows header bars. Yes the SSD under X11 was missing cropping out of CSD windows header bars when users wanted SSD control.

So some ways Arcan developer doing this is most likely someone finally doing forced SSD right. Qubes OS has had the problem for a long time of double window headers with it forced SSD when some application decides it wanting to go CSD. Please note as in problem before Wayland existed in the way up to current day.

[AHOY]

While it's not "forcing it on you", last I heard, the developer of Arcan was annoyed enough with GNOME to have implemented support for cropping out a GNOME window's header-bar and hiding it behind a toggle-button in the SSD titlebar in order to force the issue.

That's hilarious. I would go one step further and crop the entire GNOME application.