by jchw | 2025-08-08 20:14:31+00:00
I don't think it's absolutely necessary to move off of wxWidgets for Wayland support to be in decent shape in the long run. There is definitely a path forward that wxWidgets can improve its Wayland support, or KiCAD can add its own specific Wayland support bits to work around what wxWidgets can't do, if they want. It might take time, but that's OK...

There's different ways to approach it that are equally pragmatic. Any of these approaches, possibly a combination of them, seem totally reasonable to me:

- Force X11, or at least prefer it when DISPLAY is non-empty. Probably also display a warning when loading on Wayland, since the experience is known to be sub-optimal. Let things sit for a while until Wayland looks mature and well-supported enough to basically rip off the bandage. This is a good option for most programs. Krita is doing this. Users understand this, other developers understand this, etc.

- Make specific efforts to support existing Wayland compositors even in spite of its limitations. Godot has been doing borderline heroic things to make Wayland first-class (check out how they're working around the lack of something like XEmbed - it's pretty intense.)

- Participate in the process of proposing Wayland protocols or new versions of existing protocols to fill in holes gradually. It's not a fun process anymore than any other standards process, but it's a way you can help the entire ecosystem out and impart some of your knowledge/experience into the protocol design in the process.

And ultimately, I don't really think there's anything wrong specifically with listing the problems that a program has when running under Wayland, it's very helpful to have a list that people can keep track of over time (like KDE's old "Wayland showstoppers"[1] page.) I do think that KiCAD's current list is overly opinionated on what the true root issue is even when it's subjective. I think it's better to frame things more in line with what doesn't work and a first-order "why" - i.e. "Pointer wrapping does not work because the current implementation in KiCAD relies on being able to set the absolute position of the cursor which is not available on Wayland." "There are currently stability issues on Wayland that don't occur on X11." etc. 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.

I personally don't like wxWidgets very much, but it does have its advantages, and I'm sure a future can be built to be able to update wxWidgets applications to run smoothly on Wayland and maybe other future window systems, possibly by adding some new abstractions and tools.

> It's also a conglomerate of executables, so focus transfer often won't be between windows in the same process, but windows in different processes.

While that does complicate things, it's pretty tractable with some IPC. If you only need to change focus when `exec`ing (consider: this might be the case even when there's already a window open, if you're using something to do single-instancing) then it's even simpler as you can use the "standard" approach of passing the token via en environment variable on exec (then IPC'ing it to the instance in a single-instance situation.) I think this is what you want to do anyway on Linux right now, not just on Wayland.

[1]: https://community.kde.org/Plasma/Wayland_Known_Significant_I...