[HN Gopher] KiCad and Wayland Support
___________________________________________________________________
KiCad and Wayland Support
Author : xvilka
Score : 97 points
Date : 2025-06-17 09:58 UTC (13 hours ago)
(HTM) web link (www.kicad.org)
(TXT) w3m dump (www.kicad.org)
| magicalhippo wrote:
| _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.
|
| [1]: https://www.omgubuntu.co.uk/2025/05/gnome-
| dropping-x11-suppo...
|
| [2]: https://linuxiac.com/kde-x11-support-to-continue-until-
| plasm...
| toast0 wrote:
| > 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.
| LorenDB wrote:
| Not directly Wayland specific, but vaxry (Hyprland guy) is
| trying to get up a new standards body to replace
| Freedesktop.org. That could possibly accelerate the coming of
| a major shift around compositors.
| inftech wrote:
| Can you provide the source, please?
| dsr_ wrote:
| To draw a possibly inapt analogy: it was clear at a certain
| point that CVS, the king of versioning systems, was going to
| be replaced. It also seemed clear that any successful
| contender would seamlessly import from CVS, but not
| necessarily from any of the unsuccessful contenders, so it
| made sense to wait and let everyone else fight it out.
|
| (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.
| tannhaeuser wrote:
| > _Win32_
|
| 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 wrote:
| > out of their system
|
| 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 wrote:
| Yeah I think the fundamental mistake they made was trying
| to standardise a display protocol without a display server.
|
| 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.
| const_cast wrote:
| I disagree, features are added to Wayland constantly and
| we're getting more and more highly supported protocols by the
| day. We can already do 95% of what you can do on X on major
| implementations - screen sharing, global hotkeys, file
| pickers, etc.
|
| 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.
| superkuh wrote:
| It's a poor decision. Unless you're IBM/Red Hat/GNOME. Then
| it's clearly the correct decision for increasing profit. Since
| GNOME desktop (and mutter) is the only wayland desktop of the
| dozen incompatible implementations that supports accessibility
| (they invented two new protocols for it; disregarding existing
| solutions) it's basically a take-over of the entire linux
| desktop business space. No other wayland DE is ADA compliant
| and the Gtk treadmill will make X11 and it's very solid
| accesibility less likely to work with any application. Sort of
| a combination gish gallop and CADT so that they're the only
| linux desktop left that fits business use cases.
| senkora wrote:
| I had to look up some terms, so for anyone else:
|
| 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 wrote:
| We have to investigate if Windows and or Apple had their
| fingers init.
|
| 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 wrote:
| People were and are free to do so. They've chosen not to,
| though, so far.
| MegaDeKay wrote:
| Wayland messes up Visual Pinball as well [0]. VP depends on
| being able to place the main playfield window, the backglass
| window, and the Dot Matrix Display window in specific locations
| on specific monitors mounted in the cabinet.
|
| [0] https://github.com/vpinball/vpinball
| jeroenhd wrote:
| 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.
| ciupicri wrote:
| > xorg-x11-server is removed from RHEL 10
|
| > 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_
| ...)
| Vilian wrote:
| Xwayland isn't going to die in 10 years, it's fine to keep using
| that, thise bugs happens with KiCad running as Wayland or in
| xwayland?
| dvdkon wrote:
| KiCad seems to work fine under XWayland in my experience, with
| some severe bugs under Wayland (and not just window management
| & cursor warping-related, though that's a problem too).
| duped wrote:
| 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.
|
| edit: looks like pointer warping was added to the protocol last
| week: https://lore.freedesktop.org/wayland-
| devel/aEw0AP7h6T8l11ug@...
| arghwhat wrote:
| 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.
| cosmic_cheese wrote:
| The balance doesn't necessarily require that much thought or
| deliberation. It could be as simple as putting things like
| cursor control behind a permission dialog, with it being
| mandatory to provide a reason why the capability is needed to
| present in the dialog to help users make an informed
| decision.
| jeroenhd wrote:
| Web browsers tried that. Then spam sites started saying
| "press allow to prove you're not a robot". Android showed a
| whole list of permissions for years whenever you installed
| an app. Nobody ever read them, phones were full of malware,
| and Google started nuking APIs and replacing pre-install
| permission prompts with real-time permission prompts.
|
| 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.
| cosmic_cheese wrote:
| There's some crucial differences here, though.
|
| 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.
| arghwhat wrote:
| It's actually a lot more difficult than that.
|
| 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.
| cosmic_cheese wrote:
| It's a bit crude, but macOS handled the asynchronous
| prompt problem by suspending the process trying to access
| something it hasn't been given permission to use until
| the user has acted.
| duped wrote:
| > The historic reason is that all inputs and window manager
| state outside your very own window is kept secret, and
| "stealing" input strictly disallowed.
|
| 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.
| simcop2387 wrote:
| > 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?
|
| 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.
| arghwhat wrote:
| > 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.
|
| 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.
| arghwhat wrote:
| A window (surface in Wayland speak) is just an object in
| the Wayland protocol, and a Wayland client can have as many
| as it likes - it will just never see anything outside its
| windows. If these are normal windows (top-levels), it won't
| even know where the windows are relative to each other - it
| just receives (surface-relative) input when focused, none
| when not.
|
| 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.
| workethics wrote:
| This reminds me that I was recently using tracy to profile a
| program and found their own list of valid grievances, altough
| it's a bit more GNOME inflicted:
| https://github.com/wolfpld/tracy/issues/505#issuecomment-136...
| smj-edison wrote:
| It think this one is interesting since it highlights that
| Wayland is not meant to be an exclusively window manager API.
| It includes things like kiosks, car screens, etc, where the
| concept of a window doesn't even exist.
|
| 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...
| simcop2387 wrote:
| > 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.
| arghwhat wrote:
| 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.
| superkuh wrote:
| >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.
| arghwhat wrote:
| > 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.)
| DrillShopper wrote:
| > 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.
| superkuh wrote:
| It is clear that in the article and this comment thread
| your claim is the opposite that of the kicad developers.
| Your comment attempted to make it seem like their article
| was in agreement with you. That was a lie you wrote rather
| than actually saying what you meant: that you disagreed
| with the kicad developers. It's hard to believe you are
| arguing in good faith after such a disengenous start.
| Especially given your wild perception of the post-fork
| reverts of all the code which obviously weren't spurred by
| code quality but instead the fork itself.
|
| _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.
| delfinom wrote:
| 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 ;)
| arghwhat wrote:
| > 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.
|
| 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. :)
| IshKebab wrote:
| > Protocols of interest are picked up immediately and
| graduate to stable after wide adoption.
|
| Yeah... good luck changing your protocol after it's been
| "staging" for 5 years and everyone has adopted it.
| arghwhat wrote:
| Again, not how Wayland protocol maturity works. All
| released protocols are versioned, and do not break
| existing clients. Servers offer a maximum version number
| for their protocols, and clients can request any version
| up until that maximum version. If they request an older
| version, the server will behave in accordance to the
| older specification.
|
| 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.
| duped wrote:
| > Not at all how things work, no. :)
|
| 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.
| arghwhat wrote:
| No, having bugs in home-grown platform specific code is
| not at all related to whether or not the platform is
| "weird".
|
| 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.
| varispeed wrote:
| But from the post it sounds more like Wayland is just
| enshittification in open source fashion. Fewer options traded
| for...?
|
| What is the point of Wayland?
| dekhn wrote:
| The point of wayland was that the developers of X11 with the
| greatest experience concluded they no longer wanted to work
| on Xorg, and designed a new protocol taking into account
| their experience as well as knowledge of how desktops have
| changed over the past 40 years.
|
| 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.
| phkahler wrote:
| >> 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.
| arghwhat wrote:
| That's why there was a protocol released to do just that, by
| having the client set a unique tag when it creates its
| windows so the display server can recognize when a window has
| come back.
|
| 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.
| DominoTree wrote:
| I've been using KiCad on Wayland for years and didn't even know I
| was missing out
| znpy wrote:
| And again, in the year of the lord 2025, the year of linux on the
| desktop is next year.
| poulpy123 wrote:
| 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)
| mariusor wrote:
| What am I missing? For 99.9% of existing Xorg applications the
| transition should have been transparent due to the existence of
| XWayland.
|
| In which way was this transition the worst for you?
| DrillShopper wrote:
| The article talks about the many open issues with Wayland
| that do not exist in X, if you want some examples.
| mariusor wrote:
| Which seem to be self inflicted, if I'm not mistaken.
| const_cast wrote:
| Sure, _which are completely solved by Xwayland_. If your
| app doesn 't work under Wayland, then fine. Lots of apps
| don't because they're old and volatile to develop. But X11
| apps work completely seamlessly under Wayland. Every major
| desktop right now is running many X11 apps under Wayland.
| el_memorioso wrote:
| I am a Kicad user, not just a random speculator. The
| problems are not solved by XWayland. For example, Kicad
| uses different windows to represent different views of
| the circuit and circuit board and warps the cursor
| according to the view you are looking at. XWayland
| doesn't solve this, because it only allows warping within
| a single window. I know there is new warping code coming
| out, but I don't know if it will ever get into the LTS OS
| we use at my work.
| jchw wrote:
| The obvious right choice if you're on an LTS OS where
| Wayland isn't in a good enough shape is to continue using
| X11 sessions. Very few things are dropping support for
| X11 right now, and on an LTS OS you presumably would be
| insulated from that. Obviously you can't benefit from
| anything Wayland improves on, but I suspect that's not a
| huge problem.
|
| 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.
| jchw wrote:
| Some of them are not really "open" issues, which is
| blatantly obvious if you try to drag a tab in Chrome in KDE
| or GNOME: The dockable widget use case is covered by xdg-
| toplevel-drag[1], has been implemented by multiple
| libraries including Qt 6, and you can fallback to normal
| drag'n'drop with the downside that the user can't drag the
| window with the handle. A new protocol was just added for
| pointer warping[2], too. Not going to lie and say the
| surface occlusion hanging GL thing isn't annoying, but it
| is indeed solved by using fifo-v1[3] and commit-
| timing-v1[4] or the equivalent stop-gap protocols that
| existed before those ones were merged, since not everything
| is there yet. Some of these problems even had some
| workarounds prior to the proper protocols being merged;
| SDL3 already had a way to warp the pointer by (ab)using the
| existing pointer constraints API.
|
| 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
|
| [3]: https://wayland.app/protocols/fifo-v1
|
| [4]: https://wayland.app/protocols/commit-timing-v1
| IshKebab wrote:
| > 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.
| jeroenhd wrote:
| 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.
| IshKebab wrote:
| It _did_ die in the 90s! Apparently for everyone except Kicad
| (and DesignSpark PCB). I bet Eagle does it too; that 's even
| more of a UX disaster than Kicad.
| indrora wrote:
| Most of the professional tier CAD suites do it as well.
|
| 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.
| IshKebab wrote:
| > Most of the professional tier CAD suites do it as well.
|
| 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?
| BearOso wrote:
| 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.
| varispeed wrote:
| > Kicad has pretty awful UX
|
| 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.
| IshKebab wrote:
| Well yeah just because the others are bad doesn't mean Kicad
| is good! I haven't tried Altium but I've used DesignSpark
| PCB, Horizon EDA, Eagle, Kicad and Geda.
|
| 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.
| duped wrote:
| 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.
| phkahler wrote:
| 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.
| amelius wrote:
| 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)
| walterbell wrote:
| June 2025, _" The X.Org Server just got forked (announcing
| XLibre)"_, 190 comments,
| https://news.ycombinator.com/item?id=44199502
| pomerange wrote:
| 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.
| yjftsjthsd-h wrote:
| > 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.
|
| - Sent from my laptop running Xorg
| const_cast wrote:
| X11 works as well as it ever did, but it's so stagnated that
| that doesn't mean a whole lot. I run new hardware, and I
| tried X. It's bad. HDR? No. Fractional scaling? Looks awful.
| Splitting, tearing, and artifacts? Believe it or not, still a
| problem on X.
|
| 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!
| shmerl wrote:
| _> warp the mouse cursor_
|
| Wasn't cursor warping protocol just merged?
|
| https://wayland.app/protocols/pointer-warp-v1
| jchw wrote:
| 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.
| reisse wrote:
| 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...
___________________________________________________________________
(page generated 2025-06-17 23:01 UTC)