A warning would be something like "Your wayland session may have the following issues, if you can't accept that or are not comfortable investing time to work around them you may want to keep using the X11 session instead.".

Let Wayland not destroy everything and then have other people fix the damage it caused.

Sounds very different.

Let me make this crystal clear: hating women is NOT acceptable, not now, not ever.

no one here said that is was okay

I have been following this thread for over a year and I am still confused as to how we ended up with Wayland. I like analogies so here is one to express my confusion. We had a ship. It was an large old ship. Whether you liked or disliked the ship, you knew how big it was, how to steer it, provision it, sail on it, etc. It was a known quantity. One day, the operators of the ship decided they needed a new ship. They said they did not want a replacement for the old ship, just a new ship. Oh, and by the way the operators were also going to take the old ship out of service. Eventually, the ship builders delivered the new ship. However, what the ship operator received from the ship builders was a diesel engine, a propeller, and a rudder. When the operator asked about the hull and other parts of the ship, they were told by the builders that they had to create those items themselves. Because the operators were not ship builders, this lead to the construction of a very odd ship, full of quirks, missing features, and confusion for passengers who were not accustomed to the novel idiosyncrasies of the new ship.

So please help me understand why, rather than create a full featured replacement for X Window that directly addressed its shortcomings, we ended up with something replacing it that is explicitly not a replacement for it and decentralizes the implementation of key functionality. What I have heard over the year feels like attempts to rationalize the decisions made for Wayland. My interest in this is not just as a developer who relies on X Window features, but as a decades long user and believer in Linux, who is concerned that fragmentation of such core capabilities will hurt the platform.

Your analogy isn't perfect. What is missing is that the old ship can be duplicated many times within seconds and you can put a new crew on each of the duplicated old ships.

Regarding why wayland doesn't offer "all the features" I think it boils down to:

1. xorg didn't offer all the features from the start either, they were added over a long period of time. Writing a completely fully-featured new system from scratch is just not feasible and even if it were, there are just too many potential use-cases to cover that might even contradict themselves.
2. The wayland-protocols members have a very strict view on some things and prefer enabling use-cases rather than generic features that can be used in bazillion different ways. Add to that that the whole accepting-a-protocol process is *slooow*.
3. There is also xwayland support in almost every wayland compositor so running (most) X11 applications should not be an issue. This might remove some incentives to support something in a wayland protocol because there exists this fallback path.

@Consolatis Thank you for the quick and thoughtful reply.

xorg didn't offer all the features from the start either, they were added over a long period of time. Writing a completely fully-featured new system from scratch is just not feasible and even if it were, there are just too many potential use-cases to cover that might even contradict themselves.

I'm sick of reading this nonsense. Wayland has been flawed since day one. No amount of time will fix it, because the architecture is just bad.

The wayland-protocols members have a very strict view on some things and prefer enabling use-cases rather than generic features that can be used in bazillion different ways. Add to that that the whole accepting-a-protocol process is slooow.

Okay, everyone's already realized that Wayland-CСP are jerks. Where the fck is the library with all the display server features? Where the fck is it?

There is also xwayland support in almost every wayland compositor so running (most) X11 applications should not be an issue. This might remove some incentives to support something in a wayland protocol because there exists this fallback path.

Stop lying, XWayland won't run half of the applications, and those that it does run, run with limitations.

xorg didn't offer all the features from the start either, they were added over a long period of time. Writing a completely fully-featured new system from scratch is just not feasible and even if it were, there are just too many potential use-cases to cover that might even contradict themselves.

Yeah, Xorg was made in a different time when tech was way simpler. Hardware and software were way less advanced back then. Also, for something trying to replace Xorg and being the standard for many Linux distros, it can't start off incomplete like that. Wayland should've come out stronger right from the start if it wants to be the go-to choice for everyone.

Yeah, Xorg was made in a different time when tech was way simpler. Hardware and software were way less advanced back then.

The hardware and software remains exactly the same. All that has changed is mostly hardware performance.

Yeah, Xorg was made in a different time when tech was way simpler. Hardware and software were way less advanced back then.

The hardware and software remains exactly the same. All that has changed is mostly hardware performance.

Really? Did we have DRI back in the '80s? Over the years, Xorg got a bunch of extensions like Xinerama, RANDR, and more to tackle current issues. Saying Xorg was "incomplete" from the start isn't an excuse for Wayland's limitations. It aims to replace what Xorg does now, not what Xorg did decades ago.

@gustavosbarreto

Really? Did we have DRI back in the '80s? Over the years, Xorg got a bunch of extensions like Xinerama, RANDR, and more to tackle current issues.

These are improvements regarding the graphical stack that followed the development of hardware. Wayland has not invented anything new. It's just some stupid desire to "be different" for the sake of showing off or something like that.

No one back then even seriously thought of making a bunch of incompatible graphical servers with different protocols for each DE. This option has always been unsustainable.

Saying Xorg was "incomplete" from the start isn't an excuse for Wayland's limitations. It aims to replace what Xorg does now, not what Xorg did decades ago.

Absolutely agree, all the developers had to do was make an improved version of X11 and Xserver without reinventing the wheel. Either that or nothing at all.

Wayland, however, is a complete deception. First it was that Wayland was "X12", then Wayland was just a replacement for X11/Xorg. Now its fanatics are giving up and promoting it as "an incompatible modern alternative that must destroy everything before it, because the old must die. Why? Because we can."

I'm sick of reading this nonsense. Wayland has been flawed since day one. No amount of time will fix it, because the architecture is just bad.

okay @Monsterovich so you have made this claim are you able to prove it? (this is not a gotcha i would like to know)

Wayland, however, is a complete deception. First it was that Wayland was "X12", then Wayland was just a replacement for X11/Xorg. Now its fanatics are giving up and promoting it as "an incompatible modern alternative that must destroy everything before it, because the old must die. Why? Because we can."

The more I read about Wayland the more I get the impression what started as a technical issue is now rooted in ideology, almost like a social engineering op.

@Consolatis

xorg didn't offer all the features from the start either, they were added over a long period of time. Writing a completely fully-featured new system from scratch is just not feasible and even if it were, there are just too many potential use-cases to cover that might even contradict themselves.

@gustavosbarreto

Really? Did we have DRI back in the '80s? Over the years, Xorg got a bunch of extensions like Xinerama, RANDR, and more to tackle current issues. Saying Xorg was "incomplete" from the start isn't an excuse for Wayland's limitations. It aims to replace what Xorg does now, not what Xorg did decades ago.

This is a garbage reply/counter-argument.

The XFree86/Xorg server later on offered the same featureset for all its users. At no time people dealt with different levels of implementation of X11 on Linux.

This is exactly the case with Wayland. Multiple Wayland protocols are not mandatory, and the experience and features that you're getting with compositor X for Wayland could be radically different from compositor Y.

The wayland-protocols members have a very strict view on some things and prefer enabling use-cases rather than generic features that can be used in bazillion different ways. Add to that that the whole accepting-a-protocol process is slooow.

Desktop users need none of this shit. Wayland was promised to be a better X11/Xorg out of the box. It's still not by a long shot. Microsoft replaced the entire graphics stack in Vista (and moved it into user space for good measure) and even low-level Windows XP and earlier applications continued to work just fine. Some very rare applications broke, e.g. those that hooked into low-level Windows features with no public APIs, e.g. WindowBlinds, but those worked against Microsoft's will and guidelines. There's no concept of private APIs in Linux.

There is also xwayland support in almost every wayland compositor so running (most) X11 applications should not be an issue. This might remove some incentives to support something in a wayland protocol because there exists this fallback path.

Another garbage reply. XWayland is good only for running basic single-window applications because everything else is broken.

@baron1405

Your analogy is almost perfect, except you were talking about this:

However, what the ship operator received from the ship builders was a diesel engine, a propeller, and a rudder.

No, they didn't receive even that. They received blueprints for certain parts of the new ship. And those blueprints were quite vague as to whether you needed to be put them in place or not, thus we now have multiple ships, some of which are missing toilets, others are missing hallways or kitchen, others have no poles, etc. etc. etc.

And now we have multiple ships where only few selected come with all the amenities but it's claimed that they are all better than the old clunky ship.

Wayland is just a spec where x11 is a spec and implementation

I'm sick of reading this nonsense. Wayland has been flawed since day one. No amount of time will fix it, because the architecture is just bad.

okay @Monsterovich so you have made this claim are you able to prove it? (this is not a gotcha i would like to know)

I (and others) in this thread have already written thousands of proofs that Wayland is flawed, and I already post in circles sometimes.

@zarlo

Wayland is just a spec where x11 is a spec and implementation

The fact that Wayland is just a spec (and every DE has their own) is VERY BAD. The reason for this is fragmentation.

Wayland is just a spec where x11 is a spec and implementation

Well. X11 is the spec and Xorg is just one of multiple implementations, but the one practically everyone is using on the *nix desktop.

Contrast this with Wayland where not even Gnome and KDE use the same implementation, and hence are broken in different ways (as in: different features supported, different bugs).

Wayland, however, is a complete deception. First it was that Wayland was "X12", then Wayland was just a replacement for X11/Xorg. Now its fanatics are giving up and promoting it as "an incompatible modern alternative that must destroy everything before it, because the old must die. Why? Because we can."

The more I read about Wayland the more I get the impression what started as a technical issue is now rooted in ideology, almost like a social engineering op.

100%

Use DNS level adblocking, it's literally a stock Android feature (Settings > Network > Private DNS) that I don't know why more people don't use.

That isn't a solution when you realize how few adverts it can block versus ublock.

The folks behind Wayland are also the ones behind Flatpak, right?

Don't you want to be part of their wonderful utopia? Wayland + systemD + flatpak + ... secure boot with Google/Intel/AMD/Apple at the root-of-trust. Being able to enforce DRM (amongst other things) onto everyone will give us all a century of the Linux Desktop! Utopia!

Don't you want to be part of their wonderful utopia? Wayland + systemD + flatpak + ... secure boot with Google/Intel/AMD/Apple at the root-of-trust

I bet if you repeat the same strawman slop 100 more times it'll eventually be funny.

import gi

gi.require_version("Gtk", "3.0")
from gi.repository import Gtk, Gdk

offset_x = 0
offset_y = 0

def press(widget, event):
    global offset_x, offset_y
    offset_x = event.x
    offset_y = event.y

def move(widget, event):
    win.move(event.x_root - offset_x, event.y_root - offset_y)

win = Gtk.Window()
win.connect("destroy", Gtk.main_quit)
win.connect("button-press-event", press)
win.connect("motion-notify-event", move)
win.set_events(Gdk.EventMask.BUTTON1_MOTION_MASK|Gdk.EventMask.KEY_PRESS_MASK)
win.show_all()
Gtk.main()

If someone promoted something like libdecor for any X clients decades ago, we wouldn't need window managers for X.Org in the first place.

BTW, found this in Xnest logs: http://selinuxproject.org/page/NB_XWIN

You don't need a ship at all if all you need in reality is a bunch of boats.

https://en.wikipedia.org/wiki/Cossack_raid_on_Istanbul_(1615)

But ship lovers keep assuring you need a full-fledged ship to win.

That is some very weird example for you to pick. Movement of windows should belong to the user (e.g. the compositor) rather than to random applications. Anyway, running it with GDK_BACKEND=x11 (and thus via xwayland) magically makes it work for me.

That is some very weird example for you to pick

Wayland haters criticize Red Hat, GOOME or whatever for attempting to push libdecor onto everyone and enforce all the Wayland clients to support CSD, instead of accepting that every compositor should support SSD as an option and not mandate simplistic clients to support CSD, regardless of the Wayland spec.

My point is to demonstrate that X clients can in fact support CSD too, and talk to the X server directly instead of relying on some window manager to draw decorations for them and to provide ability to move and resize their windows. So if they massively did, it wouldn't be crucial to also run some window manager along with X.Org.

A decade ago, I already was willing to ditch any window managers and only use pure X.Org and small UNIX-way utilities to manage the windows. But discovered that such tools don't work without any WM at all somehow (and only years later discovered the reason: that they actually talk not to X.Org but to a WM via EWMH, and it does not even work with any WM). I was highly frustrated that if I kill a WM, X clients become totally helpless, I couldn't even change their z-order, not even focus them if I have X-Mouse disabled. Some simpler apps had CLI flags or other means to specify their initial geometry, but more normie things like browsers just launched their windows with some default geometry, not even occupying the whole screen by default as I wished.

Oh, I just checked that GTK+3 CSD apps in fact support window manipulations with pure X server and no WM too. So I did not even need to write an artificial example, hehe. Just the maximize button doesn't work (it probably works via EWMH on X11 as well).

Instead of the quirky conception of struts, I would implement the non-fullscreen maximization in a way where every window advertises its geometry to others, and tells if it allows collisions or not. Something like it happens in game engines (2D or 3D, doesn't matter). X clients would then, when changing their window geometries, query all the other windows and check if there is any room for them. Just like when you join some Minecraft server and look for an unoccupied area for your buildings lol.

How is it better than struts? Panels may occupy not the whole screen side, but only a part. Thus some space around remains, where a wallpaper can be usually seen through. There's no reason non-maximized window cannot occupy this space, but that's exactly how struts work! It would also provide a simple way to avoid physical notches: just put a dummy non-colliding window there.

Oh, and of course, if some non-colliding window appears, or changes its geometry, it should send a «посунься!!!» signal to other windows, just in the case they already occupy some space where it is supposed to appear. It could even query their geometries first and send such a signal only to those who actually occupy some space there, neat? Just make sure to avoid race conditions… somehow… transactions? And to manage conflicts, like what if two non-colliding windows claim overlapping regions the same time, what would happen?

Sounds like fun to implement in every single application. And if the application doesn't implement it you can't move the window at all as a user. Doesn't sound that great to me. Not even starting to think about features like snap to edge.

And if the application doesn't implement it you can't move the window at all as a user.

Some think splash screens are in fact a feature.

They always were frustrating to me, and I'm glad that for Word 2007 in Wine I can omit them and switch to other window anyway by putting a splash screen down, unlike for Word 2007 on Windows (but I suspect, even there it's possible to force it down via some 3rd party tools).

i hate splash screens like why show some thing just to hide it and like 99% of them dont set a sane _NET_WM_WINDOW_TYPE so tiling window managers dont know to make them auto flow

The point is to discourage the user from doing anything while the app is launched so it is launched as fast as possible and nothing interferes with the process.