These problems exist because Wayland’s design omits basic functionality that desktop applications for X11, Windows and macOS have relied on for decades—things like being able to position windows or warp the mouse cursor. This functionality was omitted by design, not oversight.
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.
> 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].
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.
I've been using Wayland for years and most applications will just work, either under XWayland or natively. The only problematic ones are the ones with incomplete Wayland implementations and the ones relying on the complete lack of security design on systems like X11 of Win32. The biggest blocker for me has always been Nvidia, and that problem was solved years ago. Meanwhile, whenever I drop back to X11, I'm reminded that things like multi-touch gestures are plainly broken on X11 mode in ever DE I've tried.
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.
I have a harsh opinion - the real problem with Wayland is that its authors and/or maintainers are *nix geeks, who never used anything more complex than X11 on an IBM Thinkpad with a maybe second 4:3 monitor attached. And they daily drive a few dozen terminal windows, Firefox and maybe Thunderbird.
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...
I have a better one: They designed for embedded devices first, desktops second or not at all. The first users of Wayland were things like vehicle infotainment systems, which operate under a limited mobile-like "one app at a time" system. Back then Ubuntu Touch (using Canonical's Mir) also looked like a prospective usecase for a new display system.
As far as I remember, the Wayland devs' approach to desktop support was "we made the basic protocol, now you desktop people either integrate functionality into the compositor (what GNOME did) or make your own extensions (what wlroots, KDE did), we don't care". With that kind of "leadership", no wonder it took years to reach even basic consensus.
Yeah I don’t know any of the details but KiCad is a pretty serious engineering gui tool and I find it easy to believe that the Wayland devs would exclude those uses cases from their designs
Quite the opposite. Wayland&Gnome are designed for tablets, phones, and barely laptops. Any usability on Desktop/Workstations is pure accident. Consider even the login screen-- it does nothing unless you do a completely inexplicable (on a mouse) click and swipe up.
As your theoretical "*nix geek" who mostly uses terminal windows, wayland and gnome provide an inferior experience to the daily driver software of 20 years ago.
At least some of them were people trying to hack X.Org to deliver an 'iPhone-like' experience on Nokia Maemo/MeeGo devices. The Jolla phone ended up being the first consumer device to ship with Wayland afaik.
A significant portion of the problems listed, e.g. performance, "unpredictable focus", glitches, freezes, etc., will generally be purely KiCad bugs.
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.
>> 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.
IMHO window restoration is the job of the DE. Implement it once there, not in every application.
>it's easy for others to read this and conflate "problems with application's Wayland support" as "problems with Wayland".
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.
Window restoration was not recently released, it was put in as experimental and it'll probably be another 5 years before it's available on stable distros as a non-experimental flag protocol.
>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 ;)
I don't have the knowledge to judge these specific issues, but the transition from X11 to Wayland was the worse I've ever seen. Worse than the python 2 to 3 debacle, and it seems even worse than the Perl 5 to 6 transition (that was resolved by not doing the transition)
Can anyone explain succinctly why basic window management and pointer warping is absent on Wayland, what it would take to fix, and how to get involved fixing it?
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.
The historic reason is that all inputs and window manager state outside your very own window is kept secret, and "stealing" input strictly disallowed.
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.
I couldn't find an explanation for the need for cursor warping support, someone in Lobsters said it might be so the "cursor could move with a moving object" which doesn't immediately resonate with me, as a frequent CAD, even LiCAD, user. Hmm.
Chances are "cursor warping" here refers to how "cursor locking" is typically done in win32 (every time the cursor moves, record the distance and reset it to the original location). Ironically, in the announcement about cursor warping being released, they say that it's not reliable for that use case, but that a "cursor lock" was already implemented. So it would be funny if KiCAD was just too stuck in Windows mentality to realize that what they needed was already supported.
Many of these limitations are in fact not Wayland issues and just limitations in KiCad (and probably more generally, wxWidgets) under native Wayland. For example, you can definitely do draggable widgets that dock and undock using xdg-toplevel-drag. What's changing with Wayland is that Wayland is no longer giving the developers the tools to implement features like session restore and docking/undocking entirely on their own, but instead forcing them to go through specific protocols. This is a point of contention that involves one's own ideals and unlikely to be resolved any time soon, but either way, this post is grossly misrepresenting the state of Wayland in general because of KiCad issues, that they are admitting they have no interest in triaging or working on anyways. That's fine, but it's still wrong.
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.
"We do not investigate or support bug reports related to Wayland-specific issues"
Well put, guys! This is the way. It wasn't broken, nobody needed to "fix it". Now they "fixed it" & it IS broken, it is not your job to pick up the pieces! I tip my hat to you for having the balls to just plainly state so.
Over the many years Wayland has been promising to be a better toaster, I have tried to use it.
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.
The only reason I use Wayland is display scaling - with a high DPI screen, many apps are blurry or inconsistently scaled under X11. Given the parade of other issues Wayland brings, I wish the development effort were instead spent on improving highDPI support in X11.
> Cursor/pointer warping: Essential for many CAD operations
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.
It's a UI pattern that I thought died in the 90s. When it works well, you don't notice the pattern is even there. When it doesn't, it looks janky as hell.
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.
When doing a fullscreen game without a visible mouse cursor, it's common to continuously warp the hidden pointer to the center and use the pointer position deltas. You could probably go lower level and use the raw device, but you end up dealing with permissions and compatibility, so it's more difficult.
I've worked on CAD software in my career, and some other domains with "special" UI considerations and it's worth pointing out that this kind of commentary is dismissed and ignored by the developers of this software, because it doesn't line up with what real users of the software report or request.
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.
Cursor warping makes sense in Blender. You can drag something past the side of the screen and it wraps back to the other side and you can still keep dragging in the same direction. In other contexts it would make sense for the cursor to lock at the edge of a widget and for the widget to scroll. Only when dragging.
IMHO window positioning is the job of the DE, which will also mean a unified behavior for all apps. Unfortunately I've been waiting years for gnome to implement this.
> but an app should never warp my cursor. It's mine. Get your stupid hands off it.
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
Wayland was designed by people who didn't quite grok the X way and decided to forge a different path. That's fine, but people also shouldn't expect Wayland to be a drop-in replacement for X in all cases. Thus a mature X-based project like KiCad is doing the right thing by focusing their efforts. If you need KiCad? You need X. If not? Run free with Wayland.
That is a odd statement since the people that designed Wayland are, by and large, the same people that maintained Xorg.
In fact the Wayland devs are the primary group of people maintaining what is left of X11.
The reality is that a lot of X11 design is simply a bad idea. Which is what one would naturally expect given its pioneering nature. By the mid 1990s it was already obsolete and didn't match up with how hardware worked nor how people were using computers.
What has allowed it to persist to this day in Linux is more along the lines of:
* we just that we had a really good open source implementation with a very dedicated developer base and some commercial support from companies like Redhat.
* compatibility with X Servers other then XFree86/Xorg was no longer relevant since the rest of the world has long abandoned X11. So aside from a few nitch cases were people wanted X11 apps on their Windows desktops using properietary X Servers it no longer really mattered.
* X11 allowed extensions (most of which didn't work with network transparency, btw)
* Widget authors, mostly QT and GTK, went through great efforts to avoid using X11 and working around limitations.
KiCAD is just a unfortunate case. They use a kinda odd toolkit, wxWidgets, and happen to depend on a lot of X11 specific behavior for some of their application's features.
So it is less of a situation of Wayland devs not understanding X (they probably are some of the few people that actually understand it deeply).
Wayland actually has really good X11 comptatibility through XWayland and for most applications it doesn't cause issues. But for KiCAD it does. And they are just being honest about it.
Accomidations are being made for KiCAD type behavior and probably KiCAD will update and change things to meet them somewhere in the middle and in not too long it'll become a forgotten issue.
Distros are not dropping Xwayland, just say "run our app trough xwayland". Recommending X11 distros or compositors is not good advice. X11 on its own is dead, and things like KDE do very little development on their X11 version.
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.
> Distros are not dropping Xwayland, just say "run our app trough xwayland".
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.
I installed kicad on an ubuntu system using flatpak (because snap was a nightmare). But now I'm running into a strange issue with X11 cookies. Anyone who's seen the same? (Using X11 of course)
[+] [-] magicalhippo|8 months ago|reply
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|8 months ago|reply
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.
[+] [-] jeroenhd|8 months ago|reply
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.
[+] [-] reisse|8 months ago|reply
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...
[+] [-] dvdkon|8 months ago|reply
I have a better one: They designed for embedded devices first, desktops second or not at all. The first users of Wayland were things like vehicle infotainment systems, which operate under a limited mobile-like "one app at a time" system. Back then Ubuntu Touch (using Canonical's Mir) also looked like a prospective usecase for a new display system.
As far as I remember, the Wayland devs' approach to desktop support was "we made the basic protocol, now you desktop people either integrate functionality into the compositor (what GNOME did) or make your own extensions (what wlroots, KDE did), we don't care". With that kind of "leadership", no wonder it took years to reach even basic consensus.
[+] [-] someguydave|8 months ago|reply
[+] [-] nullc|8 months ago|reply
As your theoretical "*nix geek" who mostly uses terminal windows, wayland and gnome provide an inferior experience to the daily driver software of 20 years ago.
[+] [-] Paianni|8 months ago|reply
[+] [-] ur-whale|8 months ago|reply
They also, in typical Unix geek style, don't give two fucks about what the market wants / needs.
[+] [-] pjmlp|8 months ago|reply
[+] [-] arghwhat|8 months ago|reply
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.
[+] [-] phkahler|8 months ago|reply
IMHO window restoration is the job of the DE. Implement it once there, not in every application.
[+] [-] superkuh|8 months ago|reply
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.
[+] [-] delfinom|8 months ago|reply
>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 ;)
[+] [-] varispeed|8 months ago|reply
What is the point of Wayland?
[+] [-] poulpy123|8 months ago|reply
[+] [-] mariusor|8 months ago|reply
In which way was this transition the worst for you?
[+] [-] DominoTree|8 months ago|reply
[+] [-] workethics|8 months ago|reply
[+] [-] duped|8 months ago|reply
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@...
[+] [-] arghwhat|8 months ago|reply
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.
[+] [-] phendrenad2|8 months ago|reply
Chances are "cursor warping" here refers to how "cursor locking" is typically done in win32 (every time the cursor moves, record the distance and reset it to the original location). Ironically, in the announcement about cursor warping being released, they say that it's not reliable for that use case, but that a "cursor lock" was already implemented. So it would be funny if KiCAD was just too stuck in Windows mentality to realize that what they needed was already supported.
[+] [-] Vilian|8 months ago|reply
[+] [-] walterbell|8 months ago|reply
[+] [-] jchw|8 months ago|reply
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.
[+] [-] dmitrygr|8 months ago|reply
Well put, guys! This is the way. It wasn't broken, nobody needed to "fix it". Now they "fixed it" & it IS broken, it is not your job to pick up the pieces! I tip my hat to you for having the balls to just plainly state so.
[+] [-] ur-whale|8 months ago|reply
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.
[+] [-] skykooler|8 months ago|reply
[+] [-] imtringued|8 months ago|reply
I've also felt no need to use KiCAD whatsoever. There are better open source EDA tools out there.
[+] [-] shmerl|8 months ago|reply
Wasn't cursor warping protocol just merged?
https://wayland.app/protocols/pointer-warp-v1
[+] [-] IshKebab|8 months ago|reply
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.
[+] [-] jeroenhd|8 months ago|reply
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.
[+] [-] BearOso|8 months ago|reply
[+] [-] duped|8 months ago|reply
[+] [-] varispeed|8 months ago|reply
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.
[+] [-] immibis|8 months ago|reply
[+] [-] phkahler|8 months ago|reply
[+] [-] bsder|8 months ago|reply
You can't implement a circular menu without pointer warp (you can, it just sucks).
[+] [-] Ballas|8 months ago|reply
I have never seen a good reason for cursor warping.
[+] [-] eviks|8 months ago|reply
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
[+] [-] LocalH|8 months ago|reply
[+] [-] lotharcable|8 months ago|reply
In fact the Wayland devs are the primary group of people maintaining what is left of X11.
The reality is that a lot of X11 design is simply a bad idea. Which is what one would naturally expect given its pioneering nature. By the mid 1990s it was already obsolete and didn't match up with how hardware worked nor how people were using computers.
What has allowed it to persist to this day in Linux is more along the lines of:
* we just that we had a really good open source implementation with a very dedicated developer base and some commercial support from companies like Redhat.
* compatibility with X Servers other then XFree86/Xorg was no longer relevant since the rest of the world has long abandoned X11. So aside from a few nitch cases were people wanted X11 apps on their Windows desktops using properietary X Servers it no longer really mattered.
* X11 allowed extensions (most of which didn't work with network transparency, btw)
* Widget authors, mostly QT and GTK, went through great efforts to avoid using X11 and working around limitations.
KiCAD is just a unfortunate case. They use a kinda odd toolkit, wxWidgets, and happen to depend on a lot of X11 specific behavior for some of their application's features.
So it is less of a situation of Wayland devs not understanding X (they probably are some of the few people that actually understand it deeply).
Wayland actually has really good X11 comptatibility through XWayland and for most applications it doesn't cause issues. But for KiCAD it does. And they are just being honest about it.
Accomidations are being made for KiCAD type behavior and probably KiCAD will update and change things to meet them somewhere in the middle and in not too long it'll become a forgotten issue.
[+] [-] pomerange|8 months ago|reply
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.
[+] [-] yjftsjthsd-h|8 months ago|reply
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
[+] [-] znpy|8 months ago|reply
[+] [-] amelius|8 months ago|reply