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

[Sonadow]

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 ↓

I don't see why the hell that should be a problem. A desktop environment's role is to launch graphical applications windows and display notifications. How windows looks doesn't even compare to a fart in the grand scheme of getting things done with a computer.

Typical case of missing the forest for the trees.

[ssokolow]

There is no security when you execute untrusted programs. The argument that "trusted chrome elements" somehow matter is invalid.

A Wayland app can pretend to have a privileged dialog box like a password entry box hovering over it if it is able to fake the system windeco, or hijack the function of windeco, such as producing a close or minimize button that appears to do so but actually uses shaped window calls to give the impression that there was a smaller, more privileged window hiding behind it.

Trusted chrome elements are part of a toolbox of elements for making it harder for applications to impersonate each other.

[duby229]

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.

And yet Gnome looks and feels far worse than it ever has... Oxymoron much? Plasma is the best looking and feeling DE in existence right now.

[curfew]

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 no security when you execute untrusted programs. The argument that "trusted chrome elements" somehow matter is invalid.

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

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

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

[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]

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.

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