XWayland 21.1 Release Candidate Offers Split From The X.Org Server

[mppix]

Not the original poster, but making sure all the decorations come from the same place is exactly the reason I want SSD. I don't want Qt, GTK+, SDL, etc. to have to reinvent the fancy functions I currently enjoy in my customized KWin windeco and its context menus.

I'm always reminded of this screenshot: https://www.reddit.com/r/linux/comme...decoration_is/

The GNOME people can argue their case after libdecoration is production-ready and has gained sufficient buy-in.

(Plus, SSD gives a desktop the ability to have trusted chrome elements on each window, which you'd think would fit with the "Security!" arguments for why Wayland is the way it is.)

The posted screenshot is obviously undesirable (although some programs, especially mediaplayers, are intentionally "non-conformant). Also FYI, I was quite surprised that Wayland compositors won't have server side decorations. However thinking about it, I kind of agree that look'n'feel should be in one place; preferably in the GUI framework and not the compositor.
I guess my thinking is that VLC or many Java applications don't integrate [much] better in Gnome only because we slap a topbar on them. They still feel out of place most of the time. Just my 2c.

[curfew]

Not the original poster, but making sure all the decorations come from the same place is exactly the reason I want SSD. I don't want Qt, GTK+, SDL, etc. to have to reinvent the fancy functions I currently enjoy in my customized KWin windeco and its context menus.

Responsibility of drawing (and possibly window management) is separate issue from extended features. There should be no obstacle why there couldn't be a centralized library that every WM used and adhered to. It's simply a design issue that can be solved but so far nobody has cared to try solving.

I'm always reminded of this screenshot: https://www.reddit.com/r/linux/comme...decoration_is/

That's fake news and only noobs buy it. Apps consist of multiple widgets, not just window decorations. I would much more prefer the decorations to integrate with the rest of the app window. Forced uniform decorations break the look-and-feel on everything else than native-to-DE apps. Gnome decorations look shit on anything else than Gnome / GTK apps. KDE decorations look shit on anything else than KDE / Qt apps.

This is an issue that cannot be solved simply through theming, especially since the feature gap between GTK and Qt is constantly growing thanks to Qt being perpetually stuck in the '90s. Even KDE folks are working to replace "native" Qt widgets with QML and their own designs.

[curfew]

Sure. Is Xwayland also an X server for X clients then?

Of course it is. Cannot run Xorg apps without a Xorg server.

[oiaohm]

(Plus, SSD gives a desktop the ability to have trusted chrome elements on each window, which you'd think would fit with the "Security!" arguments for why Wayland is the way it is.)

There is a big elephant in the room with this idea.

I will start of with some facts.
1) X11 server without a Windows manager is in fact Client Side Decorated(CSD)
2) Different applications going back though time have been Client Side Decorated big one most people know is winamp/xmms but there are tones of other examples. Yes X11 windows manager have a flag that say don't Server Side Decorate(SSD) this application. Yes this is not unique to X11 than server side decorations can be disabled or in windows case toolkit provided decorations can be disabled.

So can you in fact trust the chrome elements on each window when they could be CSD rendered and you cannot tell if they are or are not? The answer is no right. The big elephant here is that different applications due to wanting to customise things will want to do there own decorations so when you provide SSD you have to provide a off switch that off switch now means SSD are not in fact trust-able elements. The features you would be wanting in SSD as trustable chrome elements on each window as trusted really you should be after them some in form of task manager.

The hard reality real world SSD does not end up giving you a security advantage due to the off switch that has to be there so you don't end up with double title bars and other horribles, So why be paying a performance cost in having to have more memory buffers to have SSD that leads to the Wayland choice to appear as CSD only. Yes the first form of X11 protocol is CSD only as well.

Something important to remember is that wayland compositors are stack-able. This what waypipe and gamescope exploit and weston reference supports. So if gnome does not want to implement server side decorations/xdg-decoration it is possible to implement a proxy wayland compositor that runs between application and gnome exposing xdg-decoration so xdg-decoration only applications can present perfectly on gnome or any other CSD only compositor anyhow because the proxy compositor does the SSD render.

The proxy wayland compositor is a very interest design feature in the wayland design. It means not every wayland compositor has to implement every wayland feature. If a feature exists as a proxy implementation it can be used on all Wayland compositors.

Yes I would like if someone would take libdecoration and implement a matching proxy wayland compositor implementing xdg-decoration using it.

[Shiba]

Btw why do you care? Why shouldn't all decorations should come from the same place?

Because not all developers come from the same place. I actually prefer CSD, but I don't have the power to control other people's mind (yet).

It's not really big blocker. It's not like SSD is only option for every compositor. xdg-decoration is not mandatory after all.

I don't care if it's optional or not, this looks like sh*t and unless you intentionally plan to develop a desktop that looks like sh*t it is a big blocker ↓

[Mez']

Not sure about Manjaro but Ubuntu's Wayland implementation used to be fairly broken (20.04)... Should be in good shape for next release..

By the way, I was talking about a touchpad 2-finger scroll, not a mouse scroll wheel (I haven't tried). Don't know if it changes anything for you.
I would be surprised if I was an isolated case for whom it doesn't work, since it doesn't work only on wayland in 4 case scenarios (computer A + Ubuntu, Computer A + Manjaro, Computer B + Ubuntu, Computer B + Manjaro), unless I have a common denominator that interferes with it.
Of course, I could try to switch off extensions to see if there's an impact. But, in the end, it doesn't change much for me. It works with X, not with wayland. Why changing things that work (see list) for things that don't? Why would I want that?

[oiaohm]

Because not all developers come from the same place. I actually prefer CSD, but I don't have the power to control other people's mind (yet).

I don't care if it's optional or not, this looks like sh*t and unless you intentionally plan to develop a desktop that looks like sh*t it is a big blocker

The reality is a X11 desktop can look the same level of disaster mess of miss matched theming between toolkits. Really look closer. QT based application is on a light theme and GTK is on a dark theme..

CSD vs SSD really not majority of the problem. In that picture Shiba the person did not open up the different file dialog and other levels of major learning curve miss alignment.

Theming has been a on going disaster.

[ssokolow]

That's fake news and only noobs buy it. Apps consist of multiple widgets, not just window decorations. I would much more prefer the decorations to integrate with the rest of the app window. Forced uniform decorations break the look-and-feel on everything else than native-to-DE apps. Gnome decorations look shit on anything else than Gnome / GTK apps. KDE decorations look shit on anything else than KDE / Qt apps.

You're talking to someone who specifically de- integrates the themes Lubuntu comes with because the "harmonize the titlebar with the widgets" windeco that's on by default doesn't have enough contrast betweeen active and inactive titlebars.

This is an issue that cannot be solved simply through theming, especially since the feature gap between GTK and Qt is constantly growing thanks to Qt being perpetually stuck in the '90s. Even KDE folks are working to replace "native" Qt widgets with QML and their own designs.

And I actively avoided those applications until I heard they were developing a QML theme that looks more like what I'm used to.

I think flat design is Microsoft-inspired faddish trash that is proven to encourage garbage UI design, and I don't want my desktop to look like a phone or tablet UI.

I know what I want, and I'm not going to jump off the garbage UI cliff just because everyone else is.

[ssokolow]

Responsibility of drawing (and possibly window management) is separate issue from extended features. There should be no obstacle why there couldn't be a centralized library that every WM used and adhered to. It's simply a design issue that can be solved but so far nobody has cared to try solving.

I did mention libdecoration, and all I care about is results. So far, the results have been underwhelming.

[ssokolow]

There is a big elephant in the room with this idea.

1. Even if the WM doesn't support ignoring the "undecorate" flag (which a secure WM may do), Wayland+SSD allows the window manager to draw a window border that the application can't predict and fake, hijack, or overdraw. Wayland+CSD allows the application to call out to whatever common rendering code is there and then hijack the resulting functionality unless the DE goes out of its way to provide a way for the common rendering code to mark regions as "delegated back to the WM. Process events without them ever reaching the application." (And, even then, the application could still snapshot the controls and then fake a dialog using them overlaid on its body.)
2. CSD by default encourages designers to design applications that don't deal well with a window manager that forces SSD, resulting in the need for something like the Arcan developer's "If you try to force this on me, I'll implement WM-level cropping and a "hide/show" toggle button to get my SSD back.

Yes I would like if someone would take libdecoration and implement a matching proxy wayland compositor implementing xdg-decoration using it.

I'll agree with that. As I said to curfew, what I care about is results.