Boycott Wayland. It breaks everything!

Wayland.md

Think twice before abandoning Xorg. Wayland breaks everything!

tl;dr: Wayland is not ready as a 1:1 compatible Xorg replacement just yet, and maybe never will. Hence, if you are interested in existing applications to "just work" without the need for adjustments, then you may be better of not using Wayland at this point.

Wayland solves no issues I have but breaks almost everything I need. And usually it stays broken, because the Wayland folks only seem to care about Gnome, and alienating everyone else in the process. DO NOT INSTALL WAYLAND! Let Wayland not destroy everything and then have other people fix the damage it caused. Or force more Red Hat/Gnome components (glib, Portals, Pipewire) on everyone!

Please add more examples to the list.

Wayland breaks screen recording applications

• MaartenBaert/ssr#431 ❌ broken since 24 Jan 2016, no resolution ("I guess they use a non-standard GNOME interface for this")
• https://github.com/mhsabbagh/green-recorder ❌ ("I am no longer interested in working with things like ffmpeg/wayland/GNOME's screencaster or solving the issues related to them or why they don't work")
• vkohaupt/vokoscreenNG#51 ❌ broken since at least 7 Mar 2020. ("I have now decided that there will be no Wayland support for the time being. Reason, there is no budget for it. Let's see how it looks in a year or two.") - This is the key problem. Wayland breaks everything and then expects others to fix the wreckage it caused on their own expense.
• obsproject/obs-studio#2471 ❌ broken since at least 7 Mar 2020. ("Wayland is unsupported at this time", "There isn't really something that can just be easily changed. Wayland provides no capture APIs")
• There is a workaround for OBS Studio that requires a obs-xdg-portal plugin (which is known to be Red Hat/Flatpak-centric, GNOME-centric, "perhaps" works with other desktops)

Wayland breaks screen sharing applications

• jitsi/jitsi-meet#2350 ❌ broken since 3 Jan 2018
• jitsi/jitsi-meet#6389 ❌ broken since 24 Jan 2016 ("Closing since there is nothing we can do from the Jitsi Meet side.") See? Wayland breaks stuff and leaves application developers helpless and unable to fix the breakage, even if they wanted.
• flathub/us.zoom.Zoom#22 Zoom ❌ broken since at least 4 Jan 2019. ("Can not start share, we only support wayland on GNOME with Ubuntu (17, 18), Fedora (25 to 29), Debian 9, openSUSE Leap 15, Arch Linux"). No word about non-GNOME!

Wayland breaks automation software

sudo pkg install py37-autokey

This is an X11 application, and as such will not function 100% on 
distributions that default to using Wayland instead of Xorg.

Wayland breaks Gnome-Global-AppMenu (global menus for Gnome)

• https://gitlab.com/lestcape/Gnome-Global-AppMenu/-/issues/116 ❌ broken since 24 Aug 2018 ("because the lack of the Gtk+ Wayland support for the Global Menu")

Wayland broke global menus with KDE platformplugin

• https://blog.broulik.de/2016/10/global-menus-returning/ ("it uses global window IDs, which don’t exist in a Wayland world... no global menu on Wayland, I thought, not without significant re-engineering effort"). KDE had to do additional work to work around it. And it still did not work:

• https://bugs.kde.org/show_bug.cgi?id=385880 ❌ broken. ("When using the Plasma-Wayland session, the global menu does not work.")

Wayland breaks global menus with non-KDE Qt platformplugins

• https://blog.broulik.de/2016/10/global-menus-returning/ ❌ broke non-KDE platformplugins. As a result, global menus now need _KDE_NET_WM_APPMENU_OBJECT_PATH which only the KDE platformplugin sets, leaving everyone else in the dark

Wayland breaks AppImages that don't ship a special Wayland Qt plugin

• https://blog.martin-graesslin.com/blog/2018/03/unsetting-qt_qpa_platform-environment-variable-by-default/ ❌ broke AppImages that don't ship a special Wayland Qt plugin. "This affects proprietary applications, FLOSS applications bundled as appimages, FLOSS applications bundled as flatpaks and not distributed by KDE and even the Qt installer itself. In my opinion this is a showstopper for running a Wayland session." However, there is a workaround: "AppImages which ship just the XCB plugin will automatically fallback to running in xwayland mode" (see below).

Wayland breaks Redshift

• https://wiki.archlinux.org/index.php/redshift ❌ broken ("Redshift does not support Wayland since it offers no way to adjust the color temperature")

Wayland breaks global hotkeys

• albertlauncher/albert#309 ❌ broken since 7 Jan 2017 ("This is a security measure, but has the side effect of preventing applications from registering their own global hotkeys") YouTube video by René Rebe

Wayland does not work for Xfce?

See below.

Wayland does not work properly on NVidia hardware?

See below.

Wayland does not work properly on Intel hardware

• https://cfenollosa.com/blog/fed-up-with-the-mac-i-spent-six-months-with-a-linux-laptop-the-grass-is-not-greener-on-the-other-side.html ❌ broken since at least 02 Apr 2021 ("Screen tearing with the intel driver. Come on. This was solved on xorg and now with Wayland it's back.")

Wayland prevents GUI applications from running as root

• https://bugzilla.redhat.com/show_bug.cgi?id=1274451 ❌ broken since 22 Oct 2015 ("No this will only fix sudo for X11 applications. Running GUI code as root is still a bad idea." I absolutely detest it when software tries to prevent me from doing what some developer thinks is "a bad idea" but did not consider my use case, e.g., running truss for debugging on FreeBSD needs to run the application as root. https://bugzilla.mozilla.org/show_bug.cgi?id=1323302 suggests it is not possible: "These sorts of security considerations are very much the way that "the Linux desktop" is going these days".)

Wayland is biased toward Linux and breaks BSD

• https://blog.netbsd.org/tnf/entry/wayland_on_netbsd_trials_and ❌ broken since 28 Sep 2020 ("Wayland is written with the assumption of Linux to the extent that every client application tends to #include <linux/input.h> because Wayland's designers didn't see the need to define a OS-neutral way to get mouse button IDs. (...) In general, Wayland is moving away from the modularity, portability, and standardization of the X server. (...) I've decided to take a break from this, since it's a fairly huge undertaking and uphill battle. Right now, X11 combined with a compositor like picom or xcompmgr is the more mature option."

Wayland complicates server-side window decorations

• https://blog.martin-graesslin.com/blog/2018/01/server-side-decorations-and-wayland/ ❌ FUD since at least 27 January 2018 ("I heard that GNOME is currently trying to lobby for all applications implementing client-side decorations. One of the arguments seems to be that CSD is a must on Wayland. " ... "I’m burnt from it and are not interested in it any more.") Server-side window decorations are what make the title bar and buttons of all windows on a system consistent. They are a must have_ for a consistent system, so that applications written e.g., Gtk will not look entirely alien on e.g., a Qt based desktop, and to enforce that developers cannot place random controls into window titles where they do not belong. Client-side decorations, on the other hand, are destroying uniformity and consistency, put additional burden on application and toolkit developers, and allow e.g., GNOME developers to put random controls (that do not belong there) into window titles (like buttons), hence making it more difficult to achieve a uniform look and feel for all applications regardless of the toolkit being used.

Wayland breaks windows rasing/activating themselves

• https://phabricator.kde.org/D16648#470609 ("Wayland clients can't raise or activate themselves"), ❌ broken since May 27 2019

Wayland breaks RescueTime

• https://help.rescuetime.com/article/117-common-linux-issues ("One of the features of Wayland is that it prevents apps from doing precisely what RescueTime is trying to do—track activity in other windows.") ❌ broken since June 3, 2021

Wayland breaks window managers

Apparently Wayland (at least as implemented in KWin) does not respect EWMH protocols, and breaks other command line tools like wmctrl, xrandr, xprop, etc. Please see the discussion below for details.

Wayland breaks _NET_WM_STATE_SKIP_TASKBAR protocol

• https://github.comelectron/electron#33226 ("skipTaskbar has no effect on Wayland. Currently Electron uses _NET_WM_STATE_SKIP_TASKBAR to tell the WM to hide an app from the taskbar, and this works fine on X11 but there's no equivalent mechanism in Wayland." Workarounds are only available for some desktops including GNOME and KDE Plasma.) ❌ broken since March 10, 2022

References

• Chris Titus Tech: Wayland vs Xorg https://www.youtube.com/watch?v=U_MBJcD3SFI
• tildearrow: did somebody say "anti-Wayland horseshit"?

@myownfriend

No, i get the arguments for wayland, i see benefits. If windowmaker / gnustep / nextstep / openstep gets ported to wayland, i'll definately use wayland. That's the deciding factor for me. I mean if i had more time i'd look into making a port or window manager myself. However i can't i've got my own project to maintain, and work is super demanding right now.

One thing that is sort of a life time objective is to integrate my AI into window manager. Maybe this wayland thing would be an excuse to look into that.

@Martyn575
Btw, last night I thought about the performance issues you were having with Gnome so I decided to get out my Raspberry Pi 400 and install Ubuntu 22.04 beta to see how it runs Gnome 42.

First thing I noticed was that Gnome Settings properly shows the graphics driver as V3D 4.2 in an Xorg session but, in a Wayland session, it just showed Unknown Graphics Controller so there seems to be some problems that the graphics driver has under Wayland. Despite this, I didn't see anything like a 10 second wait for things to pop up in either session. The Ubuntu dock extension that mentioned actually smoothly animates into view at startup.

Also, to my surprise, everything runs significantly smoother in the Wayland session than Xorg at 1440p. I used my phone to record a 60fps video of the screen as I dragged a window around in both sessions and the Wayland session was updating at 60fps while the Xorg session was closer to 30fps. The overview animation saw a similar difference in performance. It's performance in Wayland still isn't quite on-par with my desktop though. Resizing a LibOffice Writer window was a little janky but still very acceptable. That's not surprising though considering the application needs to redraw more every frame when resizing and Broadcom's GPUs aren't exactly known to amazing even for low-power usage GPUs.

I'm really curious why Gnome was running so poorly when you tried it out on much better hardware.

Maybe later today I'll see if I can find another HDMI cable and try out how it handles a dual monitor setup.

@probonopd please add this: Wayland breaks Electron apps electron/electron#33226

@probonopd please add this: Wayland breaks Electron apps electron/electron#33226

Also not true. This one feature has an incompatibility with Wayland but Wayland doesn't "break Electron apps". Electron apps do work natively in Wayland. I've used them and that issue doesn't say anything about dropping Linux support for Electron. Saying Wayland "breaks Electron" apps is just you sensationalizing an issue.

@myownfriend do you try to soothe and underestimate the impact?

Electron apps do work natively in Wayland

Read carefully. The mentioned PR arose from the issue that happened exactly because an app was running in Wayland mode natively (otherwise, it wouldn't even be noticed).

The nightmare I predicted before starts happening.

X.Org does not need to get actually dead to be excluded from the default of major layman-oriented distributions, which would inevitably cause an avalanche of dropping the X support and the following features in GNU/Linux ports of apps completely, despite they would be still available in apps for Windows/macOS, just because those proprietary platforms are driven by sane managers who care about sales, and not by idealist technicians who sell the support.

Now see the logic @ckerr put into this decision:

skipTaskbar has no effect on Wayland. Currently Electron uses _NET_WM_STATE_SKIP_TASKBAR to tell the WM to hide an app from the taskbar, and this works fine on X11 but there's no equivalent mechanism in Wayland. There are some workarounds available on different systems, e.g. GNOME and KWin, but they some unacceptable tradeoffs, e.g. Window.is_skip_taskbar requires unsafe mode.

tl;dr I don't see a way to support this feature on Linux anymore.

This PR updates the documentation to reflect that it's only supported on macOS / Windows and makes an announcement in "breaking changes" (it's broken already, but better to document it here for visibility).

It's dead simple: doesn't work with Wayland ⇒ doesn't work on GNU/Linux at all. The fact it works in X.Org world isn't taken into account anymore. And I'm pretty sure that if the wlroots world had a working solution, it wouldn't be taken into account as well, despite you, @phrxmd, @binex-dsk and other wlroots fans try to promote it as a day-saver.

That's exactly the goal of GNOME fascists: they don't just defend their walled garden where they think they have a right to make decisions against both the users and the developers of third-party apps. They have a veto right against any changes not only to the core Wayland protocol, but even to the xdg namespace for extensions. And of course it makes them free to reject any solutions that the open source community comes up with, and restrain such solutions in a marginal status. Nothing technical here, just a matter of politics and evil corps. So the word "boycott" is pretty relevant and reasonable here.

And the main part? The feature would still work in Electron apps on Windows and macOS! Don't you notice the reputational impact Wayland puts on the whole GNU/Linux world being seen as a full-fledged desktop operating system?

@myownfriend do you try to soothe and underestimate the impact?

Not at all.

Read carefully. The mentioned PR arose from the issue that happened exactly because an app was running in Wayland mode natively (otherwise, it wouldn't even be noticed).

Yes, there's a compatibility issue when it comes to that one feature and Wayland. That doesn't mean that Electron apps don't work in Wayland. The difference between "SkipTaskbar doesn't work in Wayland" and "Wayland breaks electron apps" is huge. You're being purposely vague and hyperbolic.

That's also why, despite knowing the context I mentioned it in, you took my statement about how Gnome working well on my 5950X and decide to act like I was saying Gnome required those kinds of specs to run well. That's just how you operate: remove context so you can twist words. That's why you had nothing to say after I stated that Gnome 42 ran well on my Raspberry Pi 400 and worked noticeably better with Wayland.

And on that note I'm just going to respond to a part of your previous post that was I was responding to while you wrote this post.

So you are not aware that in the GNU/Linux world (and in the opensource world in general) it's a good practice to use the shared libraries and components rather than shipping them with every app?

Are you aware that libMutter, libKwin, and libWeston are shared libraries? The guy who started this topic is using libKwin in his DE. Interestingly, two month ago you had said some dumb shit like "If Wayland is so efficient then why didn't Raspberry Pi use it when it came out?". I won't repeat my answer to that but since then the newest release of Raspberry Pi OS now has experimental support for Wayland. This is possible because they're been running XFCE on top of Mutter since November.

Now see the logic @ckerr put into this decision:

skipTaskbar has no effect on Wayland. Currently Electron uses _NET_WM_STATE_SKIP_TASKBAR to tell the WM to hide an app from the taskbar, and this works fine on X11 but there's no equivalent mechanism in Wayland. There are some workarounds available on different systems, e.g. GNOME and KWin, but they some unacceptable tradeoffs, e.g. Window.is_skip_taskbar requires unsafe mode.

tl;dr I don't see a way to support this feature on Linux anymore.

This PR updates the documentation to reflect that it's only supported on macOS / Windows and makes an announcement in "breaking changes" (it's broken already, but better to document it here for visibility).

It's dead simple: doesn't work with Wayland ⇒ doesn't work on GNU/Linux at all. The fact it works in X.Org world isn't taken into account anymore. And I'm pretty sure that if the wlroots world had a working solution, it wouldn't be taken into account as well, despite you, @phrxmd, @binex-dsk and other wlroots fans try to promote it as a day-saver.

Not that I really care but the feature hasn't actually been removed for X11 clients. That PR just changes documentation, to reflect that it's not a bug, it doesn't remove any code.

Nobody called wlroots a day-saver, nor would it be solution if wlroots provided it's own way of doing that. More words twisted, more points gone over your head.

That's exactly the goal of GNOME fascists:

lmao holy shit. Explain what a fascist is dipshit lol

they don't just defend their walled garden where they think they have a right to make decisions against both the users and the developers of third-party apps. They have a veto right against any changes not only to the core Wayland protocol, but even to the xdg namespace for extensions. And of course it makes them free to reject any solutions that the open source community comes up with, and restrain such solutions in a marginal status. Nothing technical here, just a matter of politics and evil corps. So the word "boycott" is pretty relevant and reasonable here.

Notice how Gnome has an implementation of what was needed to support the electron feature did nothing to change electron's minds about it's Linux support. Some fascism you got there lol You even quoted that bit

There are some workarounds available on different systems, e.g. GNOME and KWin, but they some unacceptable tradeoffs, e.g. Window.is_skip_taskbar requires unsafe mode

If this was a Gnome issue then why isn't Gnome's implementation the standard? Words like "fascist" don't mean anything to you, it's just another historical buzzword you use to try to put on things because you know of it's negative connotation.

And the main part? The feature would still work in Electron apps on Windows and macOS! Don't you notice the reputational impact Wayland puts on the whole GNU/Linux world being seen as a full-fledged desktop operating system?

It literally still works in X11 lol You can't read.

The difference between "SkipTaskbar doesn't work in Wayland" and "Wayland breaks electron apps" is huge

Why do you suppose that "breaks" should mean "breaks completely"?

As Electron is a framework, the amount of breakage varies per a certain app using it. For something like qt-ponies, which needs to open lots of uncontrollable windows spread all over the screen and possibly even many screens, it's pretty crucial to avoid polluting the window switcher with these windows. Technically, it's possible to use Wayland subsurfaces of a single parent surface for that, but that wouldn't work well among different screens.

you took my statement about how Gnome working well on my 5950X and decide to act like I was saying Gnome required those kinds of specs to run well

Wasn't that @Monsterovich?

Are you aware that libMutter, libKwin, and libWeston are shared libraries?

So what?

@bq:19:30:24:/tmp/dl$ comm -12 <(ldd /usr/lib/x86_64-linux-gnu/libmutter-9.so.0|col1|sort) <(comm -12 <(ldd /usr/lib/x86_64-linux-gnu/libkwin.so.5|col1|sort) <(ldd /usr/lib/x86_64-linux-gnu/libweston-9.so.0|col1|sort))
/lib64/ld-linux-x86-64.so.2
libc.so.6
libdl.so.2
libffi.so.8
libm.so.6
libpthread.so.0
libwayland-server.so.0
libxkbcommon.so.0
linux-vdso.so.1

They don't share anything but the bare protocol, and reinvent the similar things. Okay, besides of Weston, because it lacks experimental and non-standard things at all.

That PR just changes documentation, to reflect that it's not a bug, it doesn't remove any code.

It's only the first step.

Nobody called wlroots a day-saver, nor would it be solution if wlroots provided it's own way of doing that.

Then what's the purpose of all that wall of undermining the problem highlighted in the OP like it doesn't exist in reality?

lmao holy shit. Explain what a fascist is dipshit lol

They're fascists because they strive to expand their will to the whole GNU/Linux world. Wayland was created by a RedHat developer and reflects their ideology. As they keep so many loyal users as hostages and a human shield, and embody numerous popular distributions by being their default, their actions and decisions cannot be evaluated in the same manner like they are for some small project. Just for the same reason why a developer of some small dependency voluntarily used in thousands of projects is responsible for any breakages that decisions for this tiny project involve. And GNOME and Wayland are totally not even tiny projects.

how Gnome has an implementation of what was needed to support the electron feature

It's an internal API they explicitly concealed thus explicitly announcing that they're not going to expose this possibilities to apps outside of gnome-shell, thus making the use of them an unreliable hack.

Appreciate factual discussion but please keep it civil. The f...st word is inappropriate in this context.

If you somehow think free and open source software project are lead by f***st I don't think there's enough grass to save you.

Why do you suppose that "breaks" should mean "breaks completely"?

That's what's inferred when you decide to be vague with your wording. You could specify that it breaks one feature but you decide to instead claim that it just breaks Electron.

As Electron is a framework, the amount of breakage varies per a certain app using it. For something like qt-ponies, which needs to open lots of uncontrollable windows spread all over the screen and possibly even many screens, it's pretty crucial to avoid polluting the window switcher with these windows. Technically, it's possible to use Wayland subsurfaces of a single parent surface for that, but that wouldn't work well among different screens.

How did you find this? It's cool but citing an application that puts My Little Pony characters all over the screen was probably the last thing I expected in this conversation. That being said, I just ran the Windows binary and there are indeed ponies walking all over my screen and no additionally windows displayed in Gnome's Dash. There's one window for the config window but once I close that, the ponies stay on the screen and it doesn't show anything in the Dash. This probably has everything to do with XWayland being partly integrated into the compositor but XWayland definitely translates X11 into Wayland so it would be interesting to see how this is being handled behind the scenes.

But lets assume that it did polluted the taskbar with windows, it would still serve the purpose of putting ponies all over the screen with a very notable downside of having a lot of windows in the taskbar.

Wasn't that @Monsterovich?

Yup. My bad. I get some of the people here confused sometimes.

So what?

@bq:19:30:24:/tmp/dl$ comm -12 <(ldd /usr/lib/x86_64-linux-gnu/libmutter-9.so.0|col1|sort) <(comm -12 <(ldd /usr/lib/x86_64-linux-gnu/libkwin.so.5|col1|sort) <(ldd /usr/lib/x86_64-linux-gnu/libweston-9.so.0|col1|sort))
/lib64/ld-linux-x86-64.so.2
libc.so.6
libdl.so.2
libffi.so.8
libm.so.6
libpthread.so.0
libwayland-server.so.0
libxkbcommon.so.0
linux-vdso.so.1

They don't share anything but the bare protocol

And? I clearly pointed out that they're shared libraries because it means they can be used by other DEs.

and reinvent the similar things.

That's there problem, not a protocol problem. Would you rather KDE and Gnome circumvent Wayland, create their own way of doing things, and effectively force their way of doing things on people? I mean, you seem to think that's how things work anyway yet that doesn't seem to be the case.

It's only the first step.

Actually, you know what. You're correct about this. Just noticed it adds a comment by the skip_taskbar code that says "// TODO(ckerr): remove in Electron v20.0.0"

Oh well. No big loss.

Then what's the purpose of all that wall of undermining the problem highlighted in the OP like it doesn't exist in reality?

Nobody is undermining any problems. We've been mentioning wlroots in the context of everybody talking about how you need to implement everything from scratch if you want to make your own compositor. You don't have to because you can always fork a compositor or use wlroots. Nobody was saying "Nah, it's fine that Wayland doesn't have this because wlroots implements. The point went over your head.

The idea that "Wayland dictates that every compositor reimplements the protocol from scratch" is bullshit, it just happened that two large, existing, compositors decided to implement Wayland themselves. That's all that happened and it's being spun into a bunch of bs talking points.

The Wayland protocol isn't without it's flaws and those flaws should be fixed, but acting like X11 is well-made or fixable is dillusional.

They're fascists because they strive to expand their will to the whole GNU/Linux world.

Again this is just framing. Every application or protocol is made with the intent to be used by a large amount of people.

Wayland was created by a RedHat developer and reflects their ideology.

What ideology? Also Wayland was started in 2008 but neither the client protocol wasn't stabilized until 2012 and the server protocol was stabilized in 2013. Kristian Høgsberg may have worked at Redhat when he started it but left in 2009 to work for Intel and didn't leave Intel until July 2016. He was with Intel for the first 14 releases of Wayland. By the time he left, compositors that had only ever worked with Xorg were shipping with initial Wayland support.

You can even find him talking about Wayland 1.0 as an Intel employee.

https://archive.fosdem.org/2012/interview/kristian-hogsberg.html

As they keep so many loyal users as hostages and a human shield, and embody numerous popular distributions by being their default, their actions and decisions cannot be evaluated in the same manner like they are for some small project. Just for the same reason why a developer of some small dependency voluntarily used in thousands of projects is responsible for any breakages that decisions for this tiny project involve. And GNOME and Wayland are totally not even tiny projects.

All you did right there is try to paint a picture with words but you didn't tie it back to anything. Who are they keeping hostage? How are they being kept hostage? How are they being used as human shields? What the fuck are you talking about?

how Gnome has an implementation of what was needed to support the electron feature

It's an internal API they explicitly concealed thus explicitly announcing that they're not going to expose this possibilities to apps outside of gnome-shell, thus making the use of them an unreliable hack.

And why would they do that? Is it maybe because they didn't want other application to use non-standard protocols that would only make them work on Gnome?

On 09/Apr/2022 22:35, Martyn575 wrote: <...>

So if you have a window manager under xorg, you'd have to rewrite it as a window manager and as a compositor combined and then you send the output of this through wayland protocol to the backend and then the backend just deals with it.

The window manager and the compositor don't need to be combined, you can implement it either way.

The difference between "SkipTaskbar doesn't work in Wayland" and "Wayland breaks electron apps" is huge

Why do you suppose that "breaks" should mean "breaks completely"?

Because things are either broken or not. If you want nuance, you have to add it, not pretend afterward that your statements were nuanced when they were not.

Look, I get that some people really love Wayland problems so much that they repost them in this gist every time one pops up - even if it's a minor documentation issue and it takes My Little Pony apps to find a real-world example. But in the given situation, if you are actually interested in the solution and not the problem there are two ways to solve it:

1. Use the freedesktop.org approach of engaging with the community to agree an extension to the Wayland protocols that contain an equivalent to _NET_WM_STATE_SKIP_TASKBAR, like it has been and is being done for other things that were familiar from X11 - maybe even contribute a merge request on https://gitlab.freedesktop.org/wayland/wayland-protocols/. Yes, it's slow, it requires you to do actual work, it may take a few months or years to trickle down into all compositors, but it's the way things are done and has been, mutatis mutandis, since the beginning of X11.
2. Write a set of hyperbolic posts on your favourite Gist on how this is yet another example of how Wayland intentionally breaks everything, with a sprinkling of inadequate words like "fascism".

I get that approach 2 provides more short-term emotional satisfaction and is less work, but the proper way to actually get things done and do something for the community is 1.

We don't want "an equivalent of". We want it to not break existing software.
Wayland comes in, postulates that it "is the future", and behaves like a bull in a china shop, breaking everything that has been lovingly built and tested before it entered the scene.

We don't want "an equivalent of". We want it to not break existing software.
Wayland comes in, postulates that it "is the future", and behaves like a bull in a china shop, breaking everything that has been lovingly built and tested before it entered the scene.

That's just sounds like the same factually wrong victim narrative over and over again. Want to use existing software in existing X11? Use it in existing X11.
Other people who want to use it in Wayland, including the Electron devs, will want "an equivalent of". You don't seem to be one of those people, which is fine, so at least don't get in their way.

Use it in existing X11.

That's what I've been saying all along: "Think twice before abandoning Xorg. Wayland breaks everything!" It's in the actual headline of this gist.

That's what I've been saying all along: "Think twice before abandoning Xorg. Wayland breaks everything!" It's in the actual headline of this gist.

Sure, but if you do, then you have no problem and pointing out Wayland issue makes no sense because they're not your issues, they're the issues of other people for whom "an equivalent of" is quite OK and in fact the desirable state of affairs.

That's what I've been saying all along: "Think twice before abandoning Xorg. Wayland breaks everything!" It's in the actual headline of this gist.

"Think twice before abandoning Xorg. Wayland breaks everything." is the most indirect way of saying what you actually want. Besides showing a general lack of understanding about the thing you're bitching about (You questioned Wayland even months after creating this gist), what you actually want is impossible. You want Wayland to fix all the problems of X11 in such a way that X11 applications would support it without having to change a single line of code. There's no world in which that was ever a possibility.

I'm gonna bet you've lived in the Unix/Linux world for a long time. In that time, you've never known anything but X11. It's a protocol that predates Linux. Because of that, you have no frame of reference for what this entails. Do you think that X10 applications supported X11 just by swapping the Xserver the communicated with? No. X11 was not backwards compatible with X10. Software needed to change to support it.

https://www.google.com/url?q=https://citeseerx.ist.psu.edu/viewdoc/download%3Fdoi%3D10.1.1.38.2795%26rep%3Drep1%26type%3Dpdf&sa=U&ved=2ahUKEwiVr6fp2Zr3AhV0lYkEHaYqCDMQFnoECAYQAg&usg=AOvVaw0-gWyxl91y-hN4gOjHjq8y

"We realized at the first design meeting that it was impossible to design a protocol that was
both upward compatible with X10 and able to support the different kinds of display hardware
we could foresee. Additionally, we wished to support many window management policies that X10 could not support, such as window “decoration” and tiling. This fact and the long “wish list” required a complete redesign of X.

Or since you're a fan of Apple, was Quartz backwards compatible with X11? No. XWayland exists for the same reason that XQuartz exists.

The title of this gist could just as easily be "Think twice before abandoning X11. Wayland isn't X11 and change scares me."

Yes, all Unix/Linux systems I ever used were running X11. Since 1984 all Unix/Linux systems were using it or a compatible variant of it (Xorg).

Which means that basically all graphical software written for Unix since 1984 is written for X11.

Quartz does not pretend to be "the new X11". It does not come with the pretention that everyone who writes Unix software should rewrite their software.

Yes, all Unix/Linux systems I ever used were running X11. Since 1984 all Unix/Linux systems were using it or a compatible variant of it (Xorg).
Which means that basically all graphical software written for Unix since 1984 is written for X11.

That's factually wrong, X11 came out in 1987, and backwards compatibility is limited with early software depends on whether their extensions are still supported and compatible.

Quartz does not pretend to be "the new X11". It does not come with the pretention that everyone who writes Unix software should rewrite their software.

Quartz did not pretend specifically that because X11 was not a thing in the Apple world. But it did pretend to be the new Apple graphic system in OS X onwards (note that changes from OS 9 to OS X were far more drastic than anything the Unix world has seen). And it did come with the pretention that everybody who wanted their software to work on OS X would have to switch to it in one form or other - there was a lot of complaining at the time, and the software whose authors were busy complaining continued to work under the compatibility layer, while those whose authors were developing instead of complaining stayed relevant.

That's factually wrong, X11 came out in 1987

My source was https://en.wikipedia.org/wiki/X_Window_System, "Initial release | June 1984; 37 years ago". I'll stand corrected if this is wong; however 3 years more or less make hardly a difference regarding the point.

But it did pretend to be the new Apple graphic system in OS X or newer.

I'd have no issue if Wayland said "we are the new graphic system in Fedora X and newer". Issues arise when people imply that everyone should move away from X11 - even those not using Fedora, not using Gnome or KDE, not even using Linux.

Yes, all Unix/Linux systems I ever used were running X11. Since 1984 all Unix/Linux systems were using it or a compatible variant of it (Xorg).

Xorg only came out in 2004 so that's wrong. Also throughout the 90s a bunch of companies forked X and added there own extensions which meant software wasn't compatible. That's according to Keith Packard, one of the people who worked on X11 and the creator of Xorg.

Which means that basically all graphical software written for Unix since 1984 is written for X11.

Not at all. Before X11 they made changes to the core protocol.

Quartz does not pretend to be "the new X11". It does not come with the pretention that everyone who writes Unix software should rewrite their software.

Wow. You really think that...

In fact, I'm rather pragmatic about all of this. If stuff like screensharing works, great. If it doesn't, then it's broken.

My source was https://en.wikipedia.org/wiki/X_Window_System, "Initial release | June 1984; 37 years ago". I'll stand corrected if this is wong; however 3 years more or less make hardly a difference regarding the point.

There was literally 11 releases of X in those three years. X11 was also made without testing it's implementation. The only reason X11 is still in uses is because it wasn't really worked on for like 10 years. By the time people started working on it again, many already agreed that it needed to be replaced.

I'd have no issue if Wayland said "we are the new graphic system in Fedora something and newer". Issues arise when people imply that everyone should move away from X11 - even those not using Fedora, not using Gnome or KDE, not even using Linux.

So you'd have just as much of an issue is X12 came around. Got it. Change bad.

In fact, I'm rather pragmatic about all of this. If stuff like screensharing works, great. If it doesn't, then it's broken.

Are you serious? Lol You considered it a workaround that Qt needed a Wayland plugin. To support Wayland. You considered portals to be a workaround for screen capture and even after multiple people told you that OBS official supports Wayland, you've refused to remove it from the original post. But did you add stuff to it? Of course you did lol

You're so set in your ways that you couldn't even remove the "don't install Wayland" part of your post after it was explained to you that it isn't something you install.

In fact, I'm rather pragmatic about all of this. If stuff like screensharing works, great. If it doesn't, then it's broken.

But it does, literally today, at least if your definition is "you can use screen sharing with existing software today", not "I want to use this particular software and unless all old software I'm used to works 1:1 under this new other system, I'm not going to admit it works". The latter is unachievable, just like the X11 version of Photoshop won't work with X11 under modern Linux.

That line of argument will serve only as a straw man, just like your gist, which has continues to do a bad service to Linux/Unix GUI development as a whole just by virtue of people continuing to quote the lots of inaccuracies and outdated assertions it contains and that you refuse to change.

outdated assertions it contains and that you refuse to change

Just because I want existing software to work doesn't mean my assumptions should be called "outdated". I just happen to value backward compatibility, including binary backward compatibility, very(!) highly. Because I value time very highly.

In fact, I'm rather pragmatic about all of this. If stuff like screensharing works, great. If it doesn't, then it's broken.

Come on dude. You are so full of shit. It works today, now as we speak. All the issues about screensharing you linked in the post were resolved a while ago and you cannot admit it.

Stop pretending you are pragmatic when you are literally unable to be in touch with reality.

outdated assertions it contains and that you refuse to change

Just because I want existing software to work doesn't mean my assumptions should be called "outdated". I just happen to value backward compatibility, including binary backward compatibility, very(!) highly. Because I value time very highly.

If X11 couldn't do that with X10 despite having maybe a year between the two then how do you expect Wayland to do that while improving on X11 with a 25 year gap between them?

What you want literally can't happen. The only way this could work is if Wayland was just an extension of X11 but the issue with X11 is that the core protocol needed to be changed decades ago. You don't even really seem to be refuting any of this either. You know it's not possible and that's why you want it.

If you truly valued time then you wouldn't want an entire eco system of people trying to get an old protocol to do things that it simply can't. Plus I doubt that in the future when applications come out that only support Wayland or only enable support for certain features that only Wayland has, I doubt you're going to view that as X11 breaking Wayland. Instead you're going to view that as an attack on X11 as well.

The Wayland devs never had the expectation that every application ever created for X should or would be ported to Wayland. That's why XWayland exists and it handled 99.9% of applications without change. For the remaining 0.1%, it's because the two protocols simply differ too much and that software needs to change to handle the Wayland/XDG way. That being said, because most software uses toolkits to implement X11 and Wayland support, there are applications who support both without every considering support for either. A great example would be Linux games that use SDL2. They can be launched as native Wayland clients and will actually do that but default in the next version.

@myownfriend

You could specify that it breaks one feature but you decide to instead claim that it just breaks Electron.

It's fair enough because that's how do ordinary users perceive it. As they are not involved in IT and possibly in engineering at all, they assume that everything should work by default, rather than achieving something to work is a big luck. So even a lost Internet Explorer icon is a terrible accident which means "no internet" for them.

It's cool but citing an application that puts My Little Pony characters all over the screen was probably the last thing I expected in this conversation.

Oh, not serious enough, right?

There's one window for the config window but once I close that, the ponies stay on the screen and it doesn't show anything in the Dash

Yeah, because it's a typical app made by [latent] windozers, who assume that a tray icon should be a main control center for such kind of apps. Even if the developers made a specific hack just for the GNU/Linux version, it's a no-go for the Windows build you probably run under Wine.

By the way, I'm the person who messes with replacing the Explorer's taskbar with Stardock software on Windows machines. Pretty buggy experience: the tray applet steals icons from the hidden Explorer's panel via the SDMCP service, and it often leads to lost icons, entangled icons, or not all events propagating properly. And of course, application developers usually don't even mind about the possibility of such tinkership, and assume that the tray just should always be there as Windows is believed to be "non-customizable".

This probably has everything to do with XWayland being partly integrated into the compositor

Yup, Mutter explicitly keeps a decent level of legacy compatibility for Xwayland, and allows X11 clients running under Xwayland more than it allows for native Wayland clients.

it would still serve the purpose of putting ponies all over the screen with a very notable downside of having a lot of windows in the taskbar

So everything is okay until it allows to get things done, huh?

What's the matter of running a graphical session at all, instead of running all graphical apps in full-screen DRI mode?

What's the matter of a multi-tasking operating system? Booting every application from a live CD allows to get things done too. If you need many apps, just reboot when you switch them, or buy some more computers.

/s

because it means they can be used by other DEs

How does that fix the fragmentation? It just slows it down. I had mentioned already that many of independent compositors had died away due to being unable to carry the burden of maintaining the implementation. While tens of X11 WMs still thrive.

That's there problem, not a protocol problem

This problem was intentionally put into the protocol by making it restricted and ignoring the existing use cases.

I mean, you seem to think that's how things work anyway yet that doesn't seem to be the case.

Really? They were competing and barely caring about each other all the way they exist, even after the creation of fd.o. Remember that vendor locking is a thing. Do you have any real examples of eliminating the vendor locking without external regulation?

This trend got explicitly clear when they invented the walled gardens named GNOME Shell and Plasma respectively, thus distancing from the rest of established freedesktop ecosystem and breaking interoperability and component interchangeability with it. Wayland is no more than a building material for fencing these gardens. This is one of the key moments I'm going to highlight in debunking the 2013 video, actually (yup, I still remember about that :P)

Oh well. No big loss.

https://i.kym-cdn.com/photos/images/masonry/000/645/138/98c.png

Yeah, intentionally tiny resolution. No big loss.

We've been mentioning wlroots in the context of everybody talking about how you need to implement everything from scratch if you want to make your own compositor

What should we do then with existing compositors that are gatekeeping the standard and don't allow wlroots solutions there? https://www.mail-archive.com/wayland-devel@lists.freedesktop.org/msg39978.html

but acting like X11 is well-made or fixable is dillusional

A bad solution is better than an awful solution.

Every application or protocol is made with the intent to be used by a large amount of people.

Pretty far-fetched assumption. How about apps being made for specific needs, or even for the personal needs of the developer?

What ideology?

I had explained it already. And yeah, Intel follows it too.

Oh, and the users of Intel GPUs report tearing on X.Org even with a compositor, while it's not the case for other GPUs. Coincidence? :P

Who are they keeping hostage? How are they being kept hostage? How are they being used as human shields?

The users who don't care and just download some popular distribution, see there GNOME and thinks this is the Linux. The true GNOME fans are barely hostages, they are turncoats ;D

Is it maybe because they didn't want other application to use non-standard protocols that would only make them work on Gnome?

Nah, because they don't think apps should have access to such features at all.

@phrxmd

it may take a few months or years to trickle down into all compositors

It just won't work because all compositors won't accept it.

So both approaches are pointless. What else should we do then? Push onto distributions so they remove GNOME as their default? Push onto wayland-protocols members so they exclude the Mutter developers? Ravage RedHat? All of that seems even more pointless.

Plus I doubt that in the future when applications come out that only support Wayland or only enable support for certain features that only Wayland has, I doubt you're going to view that as X11 breaking Wayland. Instead you're going to view that as an attack on X11 as well.

"foot" is a terminal emulator for Wayland. It has no X support. X breaks Wayland!