This is very much off topic for the KiCad user forum, but as I like Open Source projects, KiCad uses wxWidgets and is even paying some wxWidgets people to help with fixing bugs.
Many KiCad users probably don’t even know what wxWidgets is. But don’t worry. only software developers (that is PC software, not your uC projects) need to know about this.
One of the problems with Kiсad was the support of dark mode on the windows platform. And it was related to the library from the post above.
I see wxWidgets mentioned often enough I almost know what it means. 
Well, mainly when I have to hunt down reasons I can’t compile.
WxWidgets are a fantastic framework to develop cross platform sw!!!
Wx provides native look and feel for each Windows version.
I’m very glad Kicad embraced this great tool!
Oh nice, I wonder if KiCad 9 will start supporting dark mode on windows in a minor update!
Just highlighting that wxWidgets has some limitations that causes issues for KiCad, and was wondering if this latest update might address them.
WxWidgets have, as the other (qt) frameworks some issue.
But are IMO a great project and I’m glad the founder did choose wxW
Maybe in 9.99, a WxWidgets change is unlikely as a point upgrade to 9.0.x, too many surprises
Every now and then I attempt to dabble a little toe into desktop GUI programming, and I invested some time in QT. I quite liked the IDE, and also used it a bit for uC programming. I started disliking them when they started hiding the FOSS version and kept on pushing the commercial variant. QT has also had a long history of being a bit difficult about the FOSS version.
Because KiCad uses wxWidgets I also had a look at it (They have screenshots of a very ancient KiCad version on their website). I managed to click together a “Hello World” window in CodeBlocks in a single afternoon, and also did a bit with one of the graphical GUI design frameworks. I also ran some python examples which were about 10 lines of code to initialize & startup the wxWidgets GUI.
I did some more research, and wxWidgets is regarded as a quite easy to use and a good fit for simple to moderately complex applications. KiCad is (probably / maybe) stretching the limits of wxWidgets a bit. Years ago I read some posts about an option for KiCad to switch to another GUI library, but it was deemed too complex to change that. I’m glad that KiCad is now also contributing a bit to wxWidgets.
The nightlies will eventually once i sort out wxpython. The wxpython devs seem to have no intention to support 3.3.
9.0 will remain on 3.2
Thanks for the info!
Note for those who don’t know, wxWidgets uses odd/even versioning so 3.3 is considered a “development” release (3.2 is stable, and 3.4 will be stable). While in general wxWidgets development releases are stable enough to use in the real world, this means that more conservative Linux distributions will typically not support any of these development releases.
KiCad controls what version of wxWidgets we use on Windows and macOS, so we can move to 3.3 earlier (likely for the 9.99 nightlies / 10.0 stable release) and test how it is. But, on Linux we will likely stick with 3.2 for longer.
There is some support for the following platforms:
- Most Unix variants with X11
Intriguing, this (my emphasis) makes it sound a little like they’re moving away from X11 generally? I know there are still blocking issues for wxWidgets on Wayland but I wonder if this indicates that they’re actively pushing in that direction…
In my observations, library updates occur most quickly in flatpack.
It’s not that wx doesn’t support Wayland.
Wayland doesn’t support applications that want to be something more than a generic phone application. The issues that kicad has are mostly on Wayland’s side.
This refers to the wxX11 port, which is hardly used these days.
Typically the wxGTK port is used (via GTK 3)
So we need to wait wxpython will support 3.3? Or exists other solutions? It would be so cool to try dark mode on windows. Generally this is main feature i need in KiCad.
I am aware of the fact that the problems relate to waiting for Wayland to implement features to provide parity with X11. But, with several major distributions announcing that they intend to remove X11 completely from their repos in the next major version or two I would not be entirely surprised if support for it starts to be dropped in other places too, regardless of what anyone thinks about Wayland or their approach.
At any rate, the comment from @dsa-t clarifies that I’ve (not surprisingly!) misunderstood what that line in the release notes means, so no major change for now…