> Generally the worst offenders for Wayland support are closed source / abandoned apps that you should consider replacing.

Why? Why does a working program have to change because the windowing system decided to flip everybody the bird?

Windows doesn't do that. Linus himself will slam the wrath of God down upon anybody who breaks the kernel API. etc.

I'll go further. The whole damn problem is the fact that there is actually a choice between Gnome, KDE, Mint, etc. Windows has one window manager. macOS has one window manager.

Consequently, Linux has to wrestle with this stupidly horrible "Where is the dividing line between program, compositor, window manager, and video controller?" problem while other OSs simple put the problem where it belongs--in the damn OS.

The issue is that Wayland forced a whole bunch of shit work onto app developers because the Wayland developers didn't want to expend the work to deal with it either. (Cue jwz's "Cascade of Attention-Deficit Teenagers" rant)

Wayland is better. Take a look at copy-paste on X11 vs Wayland--well, actually, don't, X11 copy paste will make you throw up. Just use Wayland's copy-paste because you can actually figure out what your formats are.

Wayland would be okay but while DeadRat is trying to force it on everybody they aren't putting in the work to make it work for everybody.

And the app developers and users are quite rightfully salty and angry about all this.

I'd agree with you if X was actually maintained, but we need to accept that it isn't. And to be fair, 'one app can read another app's data' is a reasonable thing to break. For everything else XWayland is the intended path (imperfect as it is).

> I'd agree with you if X was actually maintained, but we need to accept that it isn't.

Which is a self-fulfilling prophecy as the Wayland developers were the X11 developers.

To be fair, I don't disagree with them. X11 was meant for a much different world.

However, the Wayland developers have made some significant architectural mistakes. Fractional DPI for scaling is a clusterfsck. The memory ownership model is disastrous and makes communicating with languages other than C/C++ actively problematic. I can go on and on.

Wayland, itself, needs more than a little bit of reboot at this point. Vulkan/DX12/Metal has won--Wayland should be built around those abstractions. WASM seems to be handling interop and bootstrap better and better--it should probably be based around that rather than DBus. Mouse/Touch/event/etc. management needs to be rethought and probably refactored as much as possible out of Wayland. etc.

I suspect a lot of the problem is of the same origin, everybody wants to have unified abstractions for mobile/web and desktop. The Wayland/Gnome people do not want to have to write code twice--once for mobile/web and once for deksptop. In reality that turns into mobile/web abstractions for everything and desktop can go suck eggs.

WASM isn't an IPC mechanism. DBus makes much more sense to use.

It's actually incredibly useful to have apps like window managers or apps that rely on manipulating user input like xcape read another apps data. In fact such are still possible just 10x as complicated as they now involve writing awful little programs in some combination of c and yaml instead of a dead simple single line shell invocation of a program.

See https://gitlab.com/interception/linux/tools

The fact that this can work at all seems to suggest that its just as possible for malicious code running as user to compromise your security and the only thing actually broken is useful apps.

> Why are display servers handling copy paste in the first place? That is not where it belongs.

It is fairly obvious that since your clipboard can hold very valuable info or be used to get you to do something that compromises your security that something privileged needs to intermediate between Application A wants to put something into a shared mailbox and Application B wants to take it out.

Maximum security implies ensuring either action is done only by deliberate user interaction eg watching for real keystrokes or mouse usage.

It also needs to be done in a standardized way that individual apps including apps you can't modify or update can work with so that an extremely basic OS function doesn't break.

Can you explain why this doesn't belong in the display server and where indeed ti does belong?

Have you tried using Zoom in-browser? That worked last time I tried, and you avoid downloading a proprietary non-system package.

This is what I need to do to to be able to share my screen in Slack or Teams.

Okay I’ll just convince everyone at my company to switch off of zoom.

I don’t mind if people want to use Wayland. And in fact I am optimistic that someday we can all use it and X will be allowed to die. What I object to is the push from Wayland supporters to consider X deprecated when in practice there are a huge fraction of users for whom X just works and Wayland doesn’t.

(And yeah, I’m aware of the distinction between Wayland the protocol and Wayland compositors. Feel free to replace “Wayland” in this message with “every Wayland compositor I’ve tried” if that makes it more correct. It doesn’t change the fact that X works for me and the push to deprecate X before there’s a solid working replacement is misguided).

People you need to communicate with especially for work are unlikely to be impressed by your reason why everyone should use a different technology.

I haven't had luck with chrom(ium,e) using scaling, or vaapi, natively on Wayland. Firefox is a far better experience for me.

I've been using Chrome natively on Wayland for over 2 years as my daily browser. There used to be lots of bugs, but over the last 4 months, the only bug I noticed was a missing insertion cursor while typing in TEXTAREAs, and that seems to have fixed itself.

In the Display pane of Gnome's Settings app, I have "Scale" set to 175%.

they'll get that settled properly at some point, since chromeos is switching to a wayland compositor.