I've been hearing about these problems for years and if all that's missing is someone to own up to fixing it, it's worth finding out.
edit: looks like pointer warping was added to the protocol last week: https://lore.freedesktop.org/wayland-devel/aEw0AP7h6T8l11ug@...
The idea is to avoid clickjacking, eavesdropping, phishing-esque windows, you name it, all which only works when an application has freedom to find other windows, place itself and steal focus and input. Even just stealing a cursor at a bad time might lead an in-progress password input to end up somewhere unintended.
It was a good intention, and it's hard to figure out where to draw the line between convenience and capability and secure design. It's absolutely impossible to ask, as everyone will demand everything, claiming even the smallest feature is the foundation of all modern computing.
Some of these things are now coming in ways that still aim to keep explicit behavior and decent control, but enable the needed usecases. Cursor warp, session restoration, picture-in-picture, etc.
If letting the application ask nicely is a good enough security measure, then you never needed to ask in the first place. When a user wants to use an application (or, what they think an application does), and the application just says "for the app to work" when the OS queries it for a reason why it needs permissions, the user is going to click permit every time. From a practical security standpoint, the application could just as easily say "I'm going to take control of your mouse OK/cancel". Which is what happens on X11, except applications just take control of your mouse whether you want to or not.
The web is a different beast because people will visit sites on a whim, plus there’s things like redirects to factor in. Friction for visiting sites is very low, which makes the spam problem much worse. Users’ desktops are a very different environment — nearly all programs that are installed are there because the user explicitly willed it. Apps can’t install themselves and users install apps at a much lower rate than they visit sites, and so the only time there’s a “spam” effect is when setting up a new machine (which could be ameliorated by account migration tools copying permissions). Furthermore, if apps start acting abusive there’s a good chance that users will remove them and seek replacements, and so it’s in apps’ best interest to not do that.
As for Android, that’s simply a bad permissions model. The iOS/macOS model in which prompts are shown when the user tries to use an associated feature is much better and appropriately triggers mental red flags when incongruent permission requests appear.
It’s never going to be perfect, but third party devs have repeatedly proven that full access to everything all the time is not a model that works for anybody but power users and above.
Working with existing applications as is requires a ditect mapping, and any restrictions or asynchronous prompts would break any existing assumptions in platform agnostic code, so it wouldn't solve things completely.
If you make something possible to do something with a permission or configuration, app developers just tell users to accept or configure to not ask, and then we're worse off than if there was no permission at all: the security is bypassed and only the inconvenience remains.
It takes a surprising amount of thought and work to do this in any meaningful way, and it cannot be done in a way that isn't somewhat disruptive.
For multi-window applications you're not inside "your own window", you own many windows. Are apps not allowed to get and set properties of windows they spawn under Wayland?
I haven't worked on desktop UI in years, but that's very surprising to me if true.
Depends on what you're calling properties of the window, wayland does of course have a number of things like that but not all of them are the same as X11 used to be. I don't believe it's got a way to get the position of your own window, and does not have a way to set the position at all since that's considered a property of the compositor's handle on the surface IIRC (not exactly the same as the window, since the compositor can be putting decorations on the surface like the title bar, controls, etc.).
A lot of it is consequences of moving some security fences around as other commenters have mentioned, because over the decades a lot of applications (not necessarily on linux or X11, but it has happened there still) have used those other barrier's leakage to do nefarious things like steal passwords, pop up ads on top of what you're doing, etc.
I would definitely support an argument that they swung the pendulum further towards "secure by default, even at the expense of what people need" but I'm actually happy they did, because it's quite a bit easier to add the functionality in after you've got something that's secure, rather than design a new barrier that breaks existing things after the fact.
Well, technically Wayland has no such thing as properties. It only has requests and events on objects, and no protocol behave like an arbitrary key value store the same way X11 atoms do.
You can't ask Wayland how big your window is or should be for example, you decide how big it is right now when you submit a graphics buffer in a requests, and the Wayland server will tell you in an event if it would like it to be a different size (say, because someone dragged a server side decoration or because the window became fullscreen).
A key difference between Wayland and X11 is that Wayland is very explicit in how functionality is defined and added.
Note that Wayland objects including surfaces does not have "properties", just requests and events. You create a surface object, create an xdg_toplevel role object to make it into a moral window, and send requests to attach and commit buffers with content, to request fullscreen, etc. In turn you get events if the display server would like you to change state, when it's a good time to start painting, etc.
It's not like X11 where a window is an arbitrary key value store that you write stuff to and cross your fingers in order to get particular behaviors.
So a very basic problem in a multiwindow app is: open a new window. Move it around. Close window. Reopen window, and reposition it where the user last placed it.
Normally that requires windows knowing where they are in absolute coordinate space on the display. From what it sounds like, that's not possible in wayland?
Note: I don't think it's productive to talk in terms of Wayland or X11 abstractions or terminology, since the problem is very simple and something that's pretty trivial to do on any desktop for the last ~25 years. Regardless of how Wayland presents the data to an application we can agree: an app opens "windows", a user moves them around, and then the app may want to recreate equivalent windows at the same position later, right?
The problem is they want it both ways. If they're not willing to support literally every use case that X supports, then Wayland should merely exist alongside X, like Emacs alongside vi, rather than removing X from so many distros and desktop environments.
EDIT: on further thought though, it's really odd that they still haven't added in optional APIs for a lot of basic window operations...
That's because like you mention, wayland doesn't look at things as "windows" like X11 used to. It's got surfaces and compositors so it's a really rather different design than the previous systems which is why there's been such an issue with transitioning some kinds of applications and why it's been so hard to get some of the window related protocols to be agreed upon. There's been a decent number of attempts at the positioning protocols that have been kiboshed because there were effective security issues because the protocol would imply that a client could take over the screen from the intended application that the user was using, if the compositor fully follows the protocol or worked the same way that X11 did. Supporting all the different use-cases like this has definitely made progress slower and harder to keep up but personally I think it's going to end up with a more comprehensive and future proofed system once it is finally getting those last couple of things that take it from an 85% solution to a 99% solution.
Others are feature requests that there were recently released protocols for e.g. window restoration and cursor warping, but with adoption needing to pick up.
Nothing negative towards KiCad team as they and the community sort things out, but it's easy for others to read this and conflate "problems with application's Wayland support" as "problems with Wayland". It's a new platform for them, and support for a new platform will always have some growing pains.
Xwayland is also under continued development, and these distribution are not dropping X11 support through Xwayland, just native X11 sessions.
Yes, it's easy because that's explicitly what they say.
>The following problems are known issues in Wayland protocols or their implementation in desktop compositors, window managers or other layers in the display stack that are beyond our ability to resolve:
So we have two opposite claims. One from the developers of kicad in this write-up with examples and one from you above.
You have the organizations maintaining entire Linux distributions with countless applications they support giving their vote of confidence based on their experiences.
You have the organizations backing and developing Wayland.
You have all the developers of Xorg ditching it and working on Wayland instead (the person vocally claiming to pick up the slack recently had almost all their work reverted when it was found to have been completely broken).
That's a lot of people voting with their time (and in some cases, money) on Wayland and its capabilities. So no it's not my claim that Wayland works vs. KiCad devs, it's the claim of everyone that actually have skin in the display server game.
(They will also agree that some features are missing, but things like focus, graphical glitches and performance are not Wayland issues, just application bugs.)
Perhaps the Wayland developers could help developers transitioning from X11 to fix those issues because those issues make Wayland look bad/unusable.
edit additionally: your major re-write of your original post changing this can be hidden from most but I, and others, saw them and responded to the original with quotes in our own comments. This is more evidence for bad faith activity.
>A significant portion of the problems listed, e.g. performance, "unpredictable focus", glitches, freezes, etc., will generally be purely KiCad bugs
The issues have been looked into and they are purely Wayland bugs.
If things work on Windows, macOS and X11 without any platform specific ifdefs, the problem is Wayland ;)
That's not how Wayland protocol maturity works. Protocols of interest are picked up immediately and graduate to stable after wide adoption. The naming was also changed to "staging" instead of "unstable" to clarify this.
(Case in point, linux-dmabuf was only recently stabilized, and many protocols in mainstream use are not "stable").
> The issues have been looked into and they are purely Wayland bugs.
Bugs reproducible only with their Wayland platform code ≠ Bugs in Wayland.
> If things work on Windows, macOS and X11 without any platform specific ifdefs, the problem is Wayland ;)
Not at all how things work, no. :)
Yeah... good luck changing your protocol after it's been "staging" for 5 years and everyone has adopted it.
A staging protocol may end up being replaced and slowly deprecated, or have more breaking changes in new versions than you would find in a stable protocol, but a client using a particular protocol can rest assured that a server offering the protocol will adhere to the same version of the protocol contract the application was written against.
It is, though. If something works as you expect on the platforms where the majority of your users are then the weird one is just going to be ignored.
Platform integrations are a lot of code, which you might have bugs in, and why people tend to use toolkits that do the work and abstract it away for you. Even if platforms look like they're providing similar high-level features, they will look nothing alike underneath. If you roll it yourself and have bugs in your code, that's fine but not the platforms fault.
What is the point of Wayland?
If there is enshittification, it's intentional on the part of the developers, and I doubt they think it's enshittification so much as sage design choices made designing an architecture they think will eventually run on billions of devices.
No wonder.
IMHO window restoration is the job of the DE. Implement it once there, not in every application.
Wayland in general is all about leaving stuff up to the display server, with the display server representing the current user and their current window management preferences.
In which way was this transition the worst for you?
I'd guess an LTS release x years from now would be a different story. Even next year possibly, based on the pace things are going lately.
Indeed, that's not a problem at all, because there are zero such things I care about. The problem is that a lot of distros and DE's are dropping support for X even though Wayland still isn't viable at all for so many people, and LTS isn't forever.
99.99% of stuff should work under XWayland.
Does Xwayland support running firefox on a remote server and opening it on my local wayland machine ?
I'm hoping the answer is yes, because every single time I've tried in the last few years, it failed and it's most definitely NOT a niche feature of X11 for me: I use it all the time.
But, I think if you really rely on X forwarding you should keep using X. The last time I used X forwarding the performance was significantly worse than newer protocols like RDP. X is a very chatty protocol, which performs poorly on a lot of networks.
Sadly, they are not.
KiCad kicked this press release out because RedHat broke mutter which broke XWayland which caused a whole bunch of us to file bugs against KiCad (and other applications) that were the fault of Wayland.
This caused a whole bunch of application developers to have to waste a bunch of time running down a bug that made it completely obvious that RedHat does ZERO testing of whether their changes break anything in the XWayland space.
KiCad for some reason chose to paint the picture that all of these are status quo issues that are not getting solved... but the rate of progress has been pretty good actually.
Some of the issues they list are also very blatantly KiCad/wxWidgets issues and not really anything inherently to do with Wayland. Seriously, "Graphical glitches" and "Application freezes and crashes" are not problems caused by your Wayland compositor.
[1]: https://wayland.app/protocols/xdg-toplevel-drag-v1
[2]: https://wayland.app/protocols/pointer-warp-v1
1. Autokey. I use this to expand abbreviations for long words and phrases I use often. This relies on being able to insert itself between the keyboard and all userland apps, and this is apparently impossible under Wayland.
2. SimpleScreenRecorder. This relies on being able to access the window contents for all userland apps, and again this is apprently impossible.
Would I be right in thinking that both trip over because Wayland enforces application privacy, so preventing applications accessing other applications resources? And if so, why isn't there a "user root" level for apps that do need to interact with other apps?
Who is saying those are impossible use cases? I think your two apps have just not updated, that happens often with software.
My attempt did last longer than previous attempts. But in the end, I gave up due to all the bugs, again. Broken input, broken rendering, broken shortcuts, broken accessibility (not just a thing for those losers who chose to be born disabled) ... it's like Wayland isn't even trying. It's hit-or-miss whether native Wayland programs or XWayland-using programs are more broken.
If you want stability and/or features, X11 remains the only choice, even in $CURRENTYEAR. ... actually, it's quite possible that all the X11 devs moving toward Wayland is responsible for the significant decrease in X11 bugs I've seen recently ... or it might just be that there's more RAM.
In theory, Wayland is beneficial for the small fraction of users with a high DPI monitor. In practice, if you try to enable it, you get a small fraction of programs that obey it correctly, a moderate fraction of programs that badly mix scaled and unscaled elements, a small fraction of programs that end up double-scaling somehow so everything is too large, and a large fraction of programs that remain tiny. Your machine is much more usable if you just leave everything small and sit closer to the monitor, occasionally using per-app controls that work just as well on X11 anyway.
I have not actually seen any other benefits of Wayland, people just tell me they allegedly exist. Sandboxing windows away from each other is pointless since all clients are unsandboxed with the same UID anyway. "All in one process" is exactly the opposite of a feature; it just means that all crashes are fatal instead of usually recoverable like they are on X11.
Maybe Wayland should spend a decade or so running its protocol to a server inside X11 first to shake out the bugs?
Err no. I don't know why EDA guys have this weird idea that cursor warping is totally normal. DesignSpark PCB does this too - when you zoom it warps the cursor! Wtf is that?
Kicad has pretty awful UX so I guess this crazy view isn't that surprising.
> things like being able to position windows or warp the mouse cursor. This functionality was omitted by design, not oversight.
Yeah again... I'll give you window positioning, but an app should never warp my cursor. It's mine. Get your stupid hands off it.
There are shortcomings to the current/recent state of Wayland (KDE hasn't had support for storing window positions until Plasma 6.4! HDR and VRR are missing from many compositors (and X11 DEs to be fair)! Fractional scaling doesn't even work right in many Linux applications!) but when it comes to design decisions, I'm mostly on Wayland's side.
It's one of the Quirks^tm of that field. Newcomers to the field go "WTF??" but the old hats go "yeah and you'll learn to appreciate it."
And you do learn to appreciate it. the cursor warping in KiCad is absolutely essential to high level operation because it means you don't think where you're zooomed to now, you point, you zoom, you've zoomed. Once you get used to some of the keyboard shortcuts to fly around the board, you get used to focusing on the center of the display rather than having to eye around looking for the component, which might be buried in a few layers of traces and vias on-screen.
Hmm I'm not sure. I've used NX, Pro/E, Solidworks and Fusion 360 very briefly and none of them did it. Which ones do?
It's much more a feature of specifically 2D CAD suites it seems; 3D comes with a different paradigm of movement, and in 2D CAD you're working in a different mindset: 3D CAD is almost all CSG, whereas 2D CAD is mostly targeted at emulating a drafting table.
Interesting. I tried very much every EDA available on the market and Kicad has no contest. Easy to learn, doesn't get in the way and you can design boards in no time.
Contrast with e.g. Altium. That one, in my opinion, is a prime example of awful UX. You have to constantly battle it to do anything.
Geda is dead now but I remember it being basically worthless.
Eagle seemed like it should be good but they've somehow screwed up every possible UX decision, sometimes in ways that I wouldn't have even thought of if I was trying. They somehow screwed up copy & paste! Look at this absolute insanity:
https://youtu.be/XHwRnunzQUE?t=35
I wonder what Tantacrul would say about that.
DesignSpark PCB is actually quite good. It's free with no limits but not open source. Has quite a dated GUI and weird zooming but other than that the UX is one of the least WTF-y I've seen.
Kicad is very powerful but the developers are clearly actively hostile to good UX.
Horizon EDA is based on Kicad's engine but fixes the UX. It's quite good but it does have a slightly confusing component model, and I have found it to be kind of slow sometimes.
I haven't tried LibrePCB yet - it does look quite good. Going to try it out for my next project.
You can't implement a circular menu without pointer warp (you can, it just sucks).
What if the hands are smart? This is a rather primitive view on UI complexity. While you should be able to block the app from changing your pointer, it doesn't make sense to not have the functionality for when it can help users
Some if not most of these bugs are 100% application bugs, very few actually used wayland compositors have performance bugs for example (but your app running in wayland native might).
With what a dumpster fire X11 has been lately its a bit weird to bet on it for your application.
Yes, just saying "Wayland is only supported through XWayland" is usually a really easy solution that does in fact just work.
> X11 on its own is dead, and things like KDE do very little development on their X11 version.
Eeeeh... I think calling X "dead" is hyperbolic. It is less actively developed, and GNOME and KDE are migrating away from it. But it still works approximately as well as it ever has, and pretty much anything except GNOME and KDE is quite likely to continue working for the foreseeable future.
- Sent from my laptop running Xorg
There's a film of jankiness that permeates X that I just don't get on Wayland. Animations don't drop frames. Things happen when they should. My text actually looks crisp. On Linux!
Wasn't cursor warping protocol just merged?
Furthermore, XWayland is not going away. If you are unwilling to support native Wayland, the way to go is somehow disable native Wayland, like by unsetting WAYLAND_DISPLAY early on in the code before initializing the toolkit or something. Krita does this and it works just fine, although it's not ideal since features like HDR or display scaling will suffer. (But does that even matter for KiCad?)
Tl;dr: reads more like developers not happy about the direction of Wayland than an actual reasoned position. Seems confused about the implications of the Wayland session. I wouldn't worry about this. You're still going to prefer the Wayland session sooner rather than later.
I really have no other plausible explanation how they could miss so many potential usecases while rebuilding the display management ground-up: screen sharing, fractional scaling, different scaling factor for different screens, color profiles, HDR, toolbars and docking, window positions, and whatever else.
In the Wayland GitLab, there are comments in the spirit of "who would ever want to use this?" for a feature requests of something present in literally any sane WM...
They also, in typical Unix geek style, don't give two fucks about what the market wants / needs.
Every single time, I had to go back to X11 because shit simply don't work.
At this point, I am dead convinced that Wayland is simply broken by design.
As a matter of fact, they justify their existence by systematically pointing out how broken the architecture of X11 is and how a "modern" replacement is severely needed.
True, X11's architecture is indeed bad and creates lots of problems.
However, unlike Wayland, it DOES WORK.
Also, and very unfortunately for Wayland, the team working on it seem oblivious to the fact that trying to replace a badly designed system does not automatically make the replacement any better.
At this point, I would call Wayland a complete failure.
Worse, they've been at it for over 15 years and it is still fundamentally unusable.
The fact that Ubuntu is planning to deprecate X11 is, at this point in time, a catastrophe as far as I'm concerned.
magicalhippo•19h ago
We do not investigate or support bug reports related to Wayland-specific issues.
For now, if you need to use KiCad on Linux, use X11.
Can totally understand their position. I've developed cross-platform applications and it was enough work without the extra headache they describe Wayland brings.
I've been thinking about ditching Windows as my primary OS for some years, but Wayland has been really detrimental to the Linux desktop. Over a decade later and it's still not production ready, at least in my tests. Yet X11 is dying it seems, with GNOME and KDE dropping support soon[1][2].
From where I stand, the intentional fragmentation of the ecosystem seems like an especially poor decision.
[1]: https://www.omgubuntu.co.uk/2025/05/gnome-dropping-x11-suppo...
[2]: https://linuxiac.com/kde-x11-support-to-continue-until-plasm...
toast0•13h ago
IMHO, Wayland will be dead before X11. There's too many things people want to do that Wayland designed out of their system. The future is likely a third system.
Probably something designed to service Win32 windowing APIs, because Win32 is basically the stable application toolkit, for better or worse.
LorenDB•13h ago
inftech•8h ago
LorenDB•5h ago
Also see this thread where Vaxry lays out his gripes with Freedesktop.org: https://xcancel.com/vaxryy/status/1934721645115224431
DrillShopper•2h ago
Too bad Hyprland's community sucks
dsr_•13h ago
(And the winner appeared to be subversion, for a couple of years, and then git came along and won decisively -- with support for importing from subversion.)
I have been assuming that Wayland would pull itself together or else someone would build a competitor that does everything X11 can do, but also backwards and in heels and doing a creditable job at running X applications. Somehow neither of these has happened yet.
I am fond of the idea of arcan -- arcan-fe.com -- being that winner, but there doesn't seem to be much traction.
ur-whale•3h ago
Wayland is indeed the subversion of window systems, can't wait for it to die and be replaced by a window system equivalent of git.
tannhaeuser•12h ago
My thoughts exactly given the progress wine/proton is making; pretty much the only success story for Linux on the mainstream "desktop" (handheld) for over ten years. Though I'm not sure about the underlying infrastructure of SteamOS (Arch-based) and/or Bazzite (fedora-based); could well be Wayland raising its ugly head there, and I just don't see a new generation of developers or sponsors willing to invest into it.
zppln•12h ago
I spent some time last year digging around in Wayland and I've got to admit that I was surprised to learn that there really isn't anything really there. Like, there is no "system". I had read that "it's a protocol" but I hadn't fully internalized it. I'm honestly a bit surprised anyone has adopted it. It almost feels like a scam. :) When I checked you couldn't even get your window decorated without an extension (that Gnome decided to not support so you have to bring your own decorator there?).
IshKebab•12h ago
They changed it so that everyone who previously just wrote a window manager now had to write an entire display server. The open source community just doesn't have that much manpower.
jchw•5h ago
Not entirely true. Now if you want to share the "display server" bits you can plug in a library like wlroots or Smithay. The real issue, if any, is that most of those bits are not standardized; or at least, only the libwayland part.
Of course, that's not even the entire story either. When X11 servers were basically entire operating systems that ran as root, implemented print servers and directly touched /dev/mem, only a lunatic would want to maintain multiple of them... but now on Linux and even some BSDs, you can fall back to GBM/DRM/KMS/libinput/etc. for most of your "hardware" needs, the OS is doing the OS things. Wayland is also just simpler than X11; The current day cleaned-up X.org is still around 5x larger by SLOC and much more complex than wlroots.
So how come GNOME and KDE both built their own display server? Well really, they didn't; they took their existing compositors they had for X11 anyway and grew Wayland server limbs out of them. In practice retrofitting Wayland into existing compositors is still hard, but if you already have written a compositor and window manager it's still probably easier than writing a new one from scratch. And for KWin, I believe they're also making use of Qt's Wayland compositor infrastructure, too.
Something that took me a long time to understand is that people are just unhappy no matter what. Not that all of their points are invalid, just, it's often not even really about that; the specific points are often just the obvious weak spots, like the classic "Wayland can't screen capture" meme (totally fair point, but persisted so long that some people still don't know it hasn't been an issue for years.) This right here is just another one of those. Notice that when many Linux distros unified towards a singular init system, systemd, people came out with pitchforks. Were they all spouting incorrect nonsense? Well, blah blah UNIX philosophy, but largely no, there were plenty of valid complaints about systemd and what it meant for the Linux ecosystem, but it wasn't really about that. Same with Wayland! Wayland did the exact opposite, and defined a set of protocols anyone could implement, allowing you to choose your compositor. Seeing as people hated what systemd did and wanted to preserve "choice" in the Linux world, you'd expect that people would like what Wayland did, but instead everyone is just pissed about fragmentation now.
You can pick apart that argument and try to figure out why it's wrong or and invalid comparison and I'm not going to try to fight anyone on that. You can also say that the argument is made by different people and maybe that's true too (though personally I believe "people who hated systemd" and "people who hate Wayland" forms more of a circle than a venn diagram.) Even if it is, the outcome is the same: you're damned if you do and damned if you don't. What I do know is that desktops on X11 stagnated with the same sorts of problems they always had and with Wayland a lot of that got unblocked. X11 will probably be in the same crappy state it's in today and Wayland will continue iterating and improving over time. I'm sure there will be a lot of pain along the way, and I agree it isn't always pretty, but it is what it is. Software isn't a beauty contest, and there's a good reason why "elegant" stuff rarely wins in the long run.
teleforce•4h ago
I feel you. I was there before and after Wayland. I was there when they promised you toward the promise land of the year of Linux Desktop and allegedly X11 is the main hurdle.
X11 is a proper system and protocol, and it seems the Wayland folks just ignore this. The two main reasons were given by them at the time were X11 has archaic architecture (reverse client and server concept) and, the X11 code is ancient and a mess. I'm kind of sold on their first idea of Linux need a clean windowing system so we can have something nice like RDP in Windows. But their second points on the codes debt is rather off. It did occur to me at the time it will be much easier to come up with a clean room implementation of X11 system and protocol rather than come up with entire new windowing system, than hope entire people and industries will use them. After all Linux basically is a clean room implementation of Unix.
I think the main problem is that at the time there's no authoritative figure like Linus on the non-kernel Linux part or what I called Linux user environment. At the time there was Miguel de Icaza of Gnome fame but at the time he seems too much involved with another promise land of Windows .Net and Linux people cannot come to term with the idea of we should just use Win32 as other comments have suggested here. It's proven later that .Net is an eventual failure as expected and Miguel reputation suffered because of that. Strangely to be honest I have never read Linus comment on Wayland but why would he? He's laser focus on the kernel and he's happy to admit using Fedora in the middle of the Red Hat Fedora bruhaha.
const_cast•7h ago
Yes, these things were designed out of Wayland, but that doesn't mean they shouldn't exist. It means the developers decided we probably shouldn't shove them into the display server. So we just put them somewhere else, and that seems to be working fine. The situation can only improve, truly.
hakfoo•3h ago
In X11, I can still use all the same core features whether I run a full KDE desktop, Window Maker and a few dockapps, or a stack of xterms that I manually position with --geometry.
It does astonish me how Wayland missed obvious killer angles when they decided to reinvent X11. People would have been excited by "Here's a rich native toolkit so all the new software will look and work and theme consistently"-- a well-known and directly user-facing friction point, so how did they miss that?
const_cast•23m ago
> "Here's a rich native toolkit so all the new software will look and work and theme consistently"-- a well-known and directly user-facing friction point, so how did they miss that?
The problem is that application toolkits are a step above window managers and compositors. That's really an application developers choice, not a desktop's choice. Developers want to use Electron, and there's nothing we can do about that.
We can get consistently themed apps... if everyone hops on Qt. Which they won't because C++ is evil. People want to shove HTML and CSS into their music player and theme it like they do a website, so here we are.
This isn't a solved problem on any platform, even really really locked down ones like iOS. Half my iOS apps are web views which don't follow the look and feel of iOS and have inconsistent behavior as compared to the system. And iOS is the best about this honestly - it's, like, way worse on Windows which has half a dozen competing toolkits from Microsoft alone.
superkuh•13h ago
senkora•12h ago
Gish gallop = “a rhetorical technique in which a person in a debate attempts to overwhelm an opponent by presenting an excessive number of arguments, without regard for their accuracy or strength, with a rapidity that makes it impossible for the opponent to address them in the time available.”, coined about a particular creationist’s debate strategy.
https://en.m.wikipedia.org/wiki/Gish_gallop
CADT = “Cascade of Attention-Deficit Teenagers”, describing a situation where software is re-written so often that filing bugs against it is useless, coined by jwz here about GNOME’s development approach: https://www.jwz.org/doc/cadt.html
jhoechtl•13h ago
At hindsight it seems such a stupid decision to fragment a small comminity by designing such a small protocol instead of revamping the existing X protocol to sane security stamdards
justinrubek•12h ago
ezst•6h ago
MegaDeKay•13h ago
[0] https://github.com/vpinball/vpinball
jeroenhd•12h ago
To be honest, I've never seen a Linux desktop that most people would call "production ready". Even in the best days, X11 and Wayland have glitches, hardware issues, and stability problems that no other platform seems to suffer from. It took until Pipewire for audio to actually work well out of the box.
As for X11, KDE and probably others will run X11 for years to come, mostly because companies like Canonical and Red Hat ship LTS versions. Whether applications will keep supporting old configurations is another question (what software still runs on Ubuntu 16.04? I wouldn't know and I bet neither do most third party vendors), but the protocol itself isn't dying any time soon. It's not allowed to by corporate contracts.
What is dying, is corporate investment into X.org and X11 targets for some desktop environments. Developers and companies that favor X11 can come together and fork those projects, or join the dev team, to ensure their desktops work like they used to. Just because IBM doesn't want to pay developers to maintain such configurations doesn't mean they suddenly stop working, just that someone else will need to apply bugfixes from then on out. The only serious attempt I've seen from people who want to keep X11 alive was that fork from that antivax anti-DEI weirdo.
ciupicri•11h ago
> The X.Org server, an implementation of the X Window System, was previously deprecated and is removed from RHEL 10. Note that the X11 protocol is not removed, which means that most applications will remain compatible through the Xwayland compositor. For more information, see Red Hat Enterprise Linux 10 plans for Wayland and Xorg server (Red Hat Blog).
(https://docs.redhat.com/en/documentation/red_hat_enterprise_...)
mid-kid•1h ago
The main reason for this is that neither major DE has implemented multi touch gestures on X11. Not that they can't be.
There's several tools you can use for things like touchpad gestures on X11 and they work well, but aren't as nice as native integration into a DE.
msgodel•3h ago