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

[oiaohm]

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.

Point 1 for you have the problem that you have applications that do in fact need to draw their own. Wine to run particular applications has to draw their own decorations or its not going to work under X11 this will be true under Wayland as well.

The point2 by Arcan developers is kind of on the right track with "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."
Except this how SSD should be implemented if you want SSD done securely and be able to deal applications that have customised CSD decorations. So this should not be force to this should be how SSD is implemented.

Please note if a WM doesn't support undecorate flag applications under X11 using the right parts of the X11 protocol can render window by the X11 server without the windows manager knowing about it so CSD again.

It may seam horrible to make CSD the default but this requires those wanting to SSD to really consider the problem of how todo it properly with all the required functionality. Existing implementations of SSD on Windows X11 and Mac OS are all broken from a security point of view because you cannot tell what is SSD and what is CSD this is very important.

There is another side to CSD you miss that relates to data secruity. You do want applications at time to be able to resist the kill button on windows boarder. Think about it WM/compositor sees that you have sent kill to application and it decides its waiting long enough and kills it this may be too early. There is more than one right choice how long should you wait for a kill to process. So some applications having SSD for timed kill and CSD for as long as application takes todo the kill could be a great feature.

I will admit doing SSD in a secure way with proper support for applications that have to be CSD so they will not look absolutely horrible will have extra overhead.

SSD done for security should have supported cropping always.

CSD default of Wayland I don't see as wrong. SSD presumed to be there has resulted in Windows Managers not having the functionality to deal with CSD windows in either a secure way or a tidy way.

[duby229]

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.


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.

That's bullshit.... Consistent look and feel was solved at least 15 years ago. It was Gnome that intentionally broke it.

[duby229]

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.

Not in a Plasma X11 session. Theming is a disaster because -GNOME- keeps breaking it.

[mppix]

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 ↓

.. what I get. Not sure if SSD vs CSD is the problem

[mppix]

Not in a Plasma X11 session. Theming is a disaster because -GNOME- keeps breaking it.

Can you post a screenshot with some any of the following applications: gimp, musicbrainz, mpv, vlc, and any java app?
I'm genuinely interested.

[mppix]

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?

No idea, sorry. Multi-touch touchpad and multi-touch touchscreen gestures work flawless with Debian testing (Gnome 3.38 Wayland) on my DELL XPS 13. No configuration required.

[Mez']

No idea, sorry. Multi-touch touchpad and multi-touch touchscreen gestures work flawless with Debian testing (Gnome 3.38 Wayland) on my DELL XPS 13. No configuration required.

Mine too (on both Xorg and wayland), just that ctrl + 2 finger scroll for zooming in gthumb on wayland is problematic.

[mppix]

Mine too (on both Xorg and wayland), just that ctrl + 2 finger scroll for zooming in gthumb on wayland is problematic.

Confirm, happens to me too (but I rarely use gthumb) -> looks like a gthumb bug.

[ssokolow]

Point 1 for you have the problem that you have applications that do in fact need to draw their own. Wine to run particular applications has to draw their own decorations or its not going to work under X11 this will be true under Wayland as well.

If security is a high concern, it's perfectly valid to force SSD and say "if an application like WinAMP refuses to call the OS-provieded windeco function that is being made into a no-op, then that's its own fault for getting double windeco. My complaint is the encouragement of making that the norm, rather than a niche case.

Existing implementations of SSD on Windows X11 and Mac OS are all broken from a security point of view because you cannot tell what is SSD and what is CSD this is very important.

Windows and macOS don't use SSD last I checked. They use an analogue to libdecoration provided by the base platform.

There is another side to CSD you miss that relates to data secruity. You do want applications at time to be able to resist the kill button on windows boarder. Think about it WM/compositor sees that you have sent kill to application and it decides its waiting long enough and kills it this may be too early. There is more than one right choice how long should you wait for a kill to process. So some applications having SSD for timed kill and CSD for as long as application takes todo the kill could be a great feature.

KDE has done this fine with SSD since before I came to Linux in 2002. You click the close button on the SSD, it sends a signal to the application, and, if the application is hung and doesn't respond within X seconds, you get a "Kill/Wait Longer" dialog.

SSD done for security should have supported cropping always.

Maybe, but I don't approve of applications making cropping necessary for non-security applications where the user just wants to force a consistent window management workflow on all applications.

[curfew]

That's bullshit.... Consistent look and feel was solved at least 15 years ago. It was Gnome that intentionally broke it.

That's a completely re-tarded thing to say. Gnome updated its UI to be from this century while legacy desktops such as KDE failed to follow suit.