[magicalhippo]

> There is definitely a path forward that wxWidgets can improve its Wayland support

Seems there's some willingness[1] to do just that.

> or KiCAD can add its own specific Wayland support bits to work around what wxWidgets can't do, if they want

From what I gather the KiCAD devs are very much against that, as it would detract manpower from the core product, ie KiCAD itself, which is understandable.

> whereas now it feels like it's just a list of complaints, sometimes without enough information to know what the actual issues might even be

Then again, I can understand their frustration. Wayland makes Python 2 to Python 3 seem like a well-executed transition. Wayland is soon older than X11 was when Wayland got started, and it's still a mess.

Though as you say, it feels (as a user) like it's improving a lot more lately. So I think the strategy of the KiCAD devs to essentially ignore Wayland for a bit longer is a good one. In a few more years support all around is likely a lot better, and then it might make sense to spend a bit of time adding bespoke Wayland code to KiCAD.

[1]: https://gitlab.com/kicad/code/kicad/-/issues/7207#note_14094...

[senko]

> Wayland is soon older than X11 was when Wayland got started

Wayland was started in 2008, X11 in 1984 (according to Wikipedia). That makes X11 41 and Wayland 17 years old, respectively. X11 was 24 when Wayland was started.

That's without considering X11 was not a fresh start (it's 11th version of an existing protocol, so it did have some baggage), and that there was an explosion in complexity in hardware, software, security and networking for the past 30 or so years.

The functionality surface area that's "table stakes" for Wayland is a lot larger than it was for X11.

[magicalhippo]

I was considering X11 first release vs Wayland start. Sure not completely apples to apples. My primary point was more that Wayland is a very old project at this point, yet in many key areas it is quite immature. Primarily on the implementation side.

[jchw]

> Seems there's some willingness[1] to do just that.

I'm glad the wxWidgets developers are being helpful here.

> Wayland is soon older than X11 was when Wayland got started, and it's still a mess.

To me the Wayland transition is less about Wayland and more about finally breaking the dependency on X.org. It was a long, long, long time coming, and there were a lot of prerequisites to get there. KMS, DRM, EGL, GBM, dmabufs, libinput, etc.

I believe the immutable aspects of Wayland are perfectly serviceable and it should have a good shelf-life. I hope to see more advantage taken of the fact that Wayland is capabilities-based, more edge-cases of protocols nailed down, and I also hope the Newton accessibility bus sees more development as it seemed very promising.

I realize people are upset at how long things take. In my opinion, community-driven open source is pretty good at long-term things and bad at short-term things. The Wayland color-management MR took five years, but paging through the threads it's easy to appreciate the amount of thought that went into it and feel like it really lays a solid foundation for the future. With desktop systems evolving about as slowly as ever, I think this a tractable situation, and being a daily driver of Wayland on several devices I feel like it's been a long time since I felt the free software desktop was this close to parity with the competition in terms of features and to some extent, even productivity, dare I say. (I really like what KDE Plasma has done.) I honestly think the most major blocker for Wayland remains full parity for NVIDIA devices, and from that point forward the real main challenge for the Linux desktop will go back to being software and hardware support as it arguably once was.