What about all the portals built by Redhat that allow kde and wlroots to tap into screen recording, audio, and soon even key captures? I get that Redhat doesn't actively submit patches to wlroots, but they also seem to be making stuff as open as seems reasonable.

As a Sway user, I haven't noticed anything that works on Gnome but not Sway, except for stuff like Zoom, which hasn't, until recently, used the portals.

wlroots & kde both have their own xdg-desktop-portal-*[1][2]'s, which don't seem to be built by Red Hat.

xdg-desktop-portal itself originates from Flatpak[3], which makes me think it's more like to related to Canonical/Ubuntu rather than being something RH drove.

[1] https://github.com/emersion/xdg-desktop-portal-wlr https://news.ycombinator.com/item?id=32008412 (2 pts, 30 min ago)

[2] https://github.com/KDE/xdg-desktop-portal-kde

[3] https://github.com/flatpak/xdg-desktop-portal

You're thinking of Snaps which are a Canonical thing, RedHat has been heavily into Flatpak.

Link [4] that I sent you says otherwise. You should find some links to back your position.

> I really wish some other non-Gnome-favoring company would find a reason to dump a lot more money into Wayland and help move it forward in the not-only-gnome-favorable path. This is not a thing that will move forward without full-time workers. X has always had a lot of paid people contributing to it.

My understanding is most of the work is, deliberately, not in Wayland itself. In fact if you read feature and bug discussion between users and Wayland devs, it kinda seems like Wayland doesn't do much at all and has no interest in doing more.

I haven't looked into it, but wouldn't be a bit surprised if RH had a hand in that architectural decision. Definitely makes it harder to compete with Gnome.

The Wayland developers do this because they absolutely do not want to be involved in the perpetual fights between desktops. Getting into that is a lose-lose proposition. So they focus only on the small subset of things that every desktop agrees on. Users that aren't actively working on an implementation in a desktop unfortunately don't have any place in this discussion, practically they just have nothing meaningful to contribute. It's not feasible without some implementation "sponsoring" the relevant code. Piling more features into upstream Wayland to please these users is not going to help anything, the implementations will not be able to use it and it will just complicate things for no gain and create more fragmentation. This is not specifically a Wayland thing, it was also the case in the X server if you were developing a new extension, you needed to gather feedback from the WM implementations before doing anything.

If you want to make it easier to develop alternatives to GNOME, it would be best to start putting more reusable features into libraries, and getting all desktops (including GNOME) to use them. That way you have a common baseline that everyone can depend on. That may seem counter-intuitive but it is the only way, libraries provide implementations and it is actually the implementations themselves that are the important part to users, not anything that upstream is doing. The simplest example is something like Mesa. All the Wayland servers want to support hardware acceleration, so they all implement the relevant extensions, and then they're able to support applications that talk using the Mesa libraries.

You've nailed the point and failed to get to the right conclusion.

> So they focus only on the small subset of things that every desktop agrees on

It's the old "but I can't do screenshots or screen sharing" again. The desktop may agree on this, but 90% of the users are like "I don't care, just make it work" - and by catering to what desktops agree on and completely ignoring things that at least some good percentage of every desktop will use, they kinda made a mess. It might be an architecturally superior mess but not even the people who have been tinkering with their Linux boxes for 20 years seem enthusiastic about wayland. Not everyone wants to first implement features in their window manager of choice.

>It's the old "but I can't do screenshots or screen sharing" again.

I don't know what this refers to. The screenshots and screensharing are done through the xdg portal and pipewire. That's as "standard" as something across desktops can be, but like I said it just is done in a separate library/daemon rather than being in wayland upstream. You don't need to really implement anything in your window manager of choice if you already have support for those, you just use pipewire. They all agree on it. The implementations haven't ignored this, you're telling me I didn't get to the right conclusion but your conclusion is to just keep barking up the wrong tree and hope they change their mind, when they have even less incentive to do that now because the feature is already implemented elsewhere in a much better way.

>but not even the people who have been tinkering with their Linux boxes for 20 years seem enthusiastic about wayland

I don't consider this to be a problem. The tinkerers get most excited when you hand them something with a giant config file (e.g. xorg.conf) with every option under the sun that they can tweak and watch it fall apart. Most upstream maintainers I've talked to would very much like to get rid of these giant config files because they are completely untestable and unmaintainable. The tinkerers cannot have their cake and eat it too.

Not really, I'm just saying I know enough people who are usually enthusiastic and knowledgeable and they still try out wayland once a month or so and it's always "oh, found 3 thing that don't work" and go back. They're not excited if they have to fix dualscreen working or something so basic.

Yeah, that's the fragmentation part thing. I have no idea how to properly solve it, but I'm sure throwing lots of money at the problem would help.

Some just needs to fork gnome and make windows98 style UI.

This is actually OT because this is about GTK, which is a fine toolkit even if it's not C++. It has binding for most languages.

[Author of original article here]

That fork of GNOME with a Win9x-style UI exists: it's called Cinnamon.

It's OK and it's quite popular. It's a lot more customisable and versatile than GNOME's own GNOME-Classic or GNOME-Flashback sessions, but it's still really quite clunky compared to, say, MATE or Xfce.

If GNOME-Classic or GNOME-Flashback worked a little better, so that one could rearrange panels and add/move/remove controls and so on, I suspect that there would be no need for MATE to exist.

I personally find Xfce to support more of the customisations I personally want (such as a vertical taskbar with horizontal rows of components and controls) than MATE, or KDE come to that.

Wayland, for me, delivers nothing I really want. I read about variable refresh rates, HiDPI support, smooth flicker-free animations and so on, but I don't actually want or need any of those things. I don't get flicker or tearing as it is, and X.11 does all I need: seamless multihead support with 3D acceleration, and so on. I frankly prefer a minimum of animations and fades and so on.

XFCE is GTK based, and so is MATE, which is actually a fork of Gnome.

But they need to either get with Wayland or fork a modern gnome and change the UI.

Forking something and keeping it in a past state isnt really as useful as some think. See OpenOffice vs LibreOffice for example.

> I really want to see Wayland move forward and succeed,

Honest question. Why? Or, what are you hoping will be different if this occurs as opposed to the current status quo?

Because, despite the fact that Wayland originally underestimated the size of the problem, it is in theory a better technical solution to our modern graphics problems than X11. It is designed in a more secure way (there is more isolation between the apps, which is both a blessing and a curse), every frame is indeed perfect, and it provides a sane solution to the 'compositing' problem.

It's just a shame it was made into something that is even more fragmented than X11 due to it being even less than what X11 tries to be. So much got undefined by the protocol and left as something to be solved by the Compositor, and we don't have an universal compositor.

And it's not like companies are throwing money at X11 either: progress is not happening there.

X11 is a fairly mature piece of software, though. It's been around for decades, and as usual, when things stick around for that long, it's because they work fairly well. I'm not sure what progress you'd expect to see there.

I guess I don't see why software that's been around for a few years longer than I've been alive, and has never really caused me much headache needs to be replaced with software that is an immature and in many ways, a worse offering.

I see people talking about screen tearing, but X11 supports vsync on most video cards, so I really don't quite get where that's coming from.

X11 makes tear-free drawing possible.

Wayland, IIUC, makes tear-free drawing inevitable.

I guess if screen tearing is the worst thing you know, you wake up in cold sweat every night screaming its name, I guess you should really use Wayland. But for other people?

Right, I never got this. Every time the X11 vs. Wayland thing comes up, I see so many people talking about tear-free rendering as if it were on the same footing as curing cancer.

(Regardless, I haven't seen screen tearing on X11 in... close to a decade? More? I don't care if that's the case only because it's "possible", and not because it's "inevitable". Who cares? It works fine.)

Have you ever seen a film or a TV show that had screen tearing in it? I haven't, it would look awful. For anything that needs to animate smoothly at a stable frame rate, tearing is a bug. It makes it look really choppy. You can do various things to eliminate a lot of tearing in X (like using an X compositor, and only using clients that implement double buffer vsync), but the default in X is that clients can send drawing commands at any time. Wayland changes this and makes it so you're practically guaranteed to never see tearing by default.

I've used X11 for like 20 years and done all sorts of things, including watching video and even doing video editing, and this has never been an issue I've so much as thought about.

I don't know how that could be possible, I find tearing to be incredibly noticeable when doing video editing. If you're getting it when trying to do transfers between frame rates it will potentially screw things up, because you're not able to see the actual frame rate. Occasionally I still see a youtube video where someone recorded a screencast and was getting tearing, and I find it really jarring.

Dunno, maybe it's just not something I'm noticing at all. Some people seem incredibly bothered by it, but I just barely notice it if I'm not actively looking for it.

I'm far more annoyed by the added input delay and sluggishness from vsync. I want frames on the screen as fast as possible.

I don't know how you can't notice it when doing video editing, you have to actively notice the frame rate to do it right. Any choppiness will be evident. Also I really don't understand your second paragraph. You can't get rid of input delay or make frames appear faster by disabling vsync. When you mux the video you target a specific frame rate, the common formats are almost always 24, 25, 30, 60, or multiples of those. The frames are appearing the same, it's whatever is in the video file.

Any form of sane security. X11 can’t be made secure unless you go full nested X servers, where you are back to square 1 (cut holes for screen sharing and the like).

Why do you think it underestimated the problem? I am fairly sure it was a deliberately small core with an extensible (and queryable!) protocol model, exactly to be able to later develop more and more features.

There is no way to ship a full X11 replacement in one go, especially not in a bazaar-style platform.

Part of the puzzle:

The Real Story Behind Wayland and X - Daniel Stone (linux.conf.au 2013) https://www.youtube.com/watch?v=RIctzAQOe44