It's a bit sad that a GUI library absolutely needs to be new and shining to be even considered nowadays, it looks like the whole programming world got infected by JS ecosystem anything-that-is-more-than-3-months-old-is-obsolete mindset.
You definitely should have been able to link statically, but my point was that these DLLs are already available on the wxWidgets site, you didn't need to upload them yourself...
Interesting that you've decided to provide your own wxWidgets DLLs instead of using the official ones (see https://www.wxwidgets.org/downloads/). Is there some reason for this or did you just not know about the existence of the latter?
Well, there is only so much latitude for naming the event (or message, callback, whatever) sent when a window needs to repaint itself. Qt has `paintEvent()` too and nobody calls it MFC-like AFAIK. IME people mostly think about event table macros when they say it.
This was indeed the case. In 1995. Since then just about everything has changed, but the idea that wxWidgets is MFC-like still refuses to die... Another common related opinion is that you have to use macros when using wxWidgets, which couldn't be further from truth since ~15 years (see
https://wxwidgets.org/blog/2023/05/are-macros-required-to-us...) but, again, old impressions linger.
This shouldn't be the case. If you use wx 3.0, it's too old to support the features that appeared in macOS after its release (dark mode etc), but 3.1.5 should look just as the native UIs do.
Best size is determined by each window. Min size is best size by default, but can be set to something different to override it. And the initial size is also min size by default, because this is what you'd expect: if you create a text entry wide enough for 50 characters, you don't want it to shrink to its best size which would be smaller. Generally speaking, it's best to avoid hardcoding any sizers (and definitely never use sizes in pixels).
For the relayout, the general principle is that it _always_ flows from top to bottom, i.e. changing anything for a child will _never_ affect the size of a (grand) parent. So you just need to call Layout() on the top-most window whose size you want to allow changing. Again, this might be too simple, perhaps, but at least it is simple and 100% consistent (well, wxCollapsiblePane just might be one of the very few exceptions...). I'm not sure how does Qt manage to avoid confusion if it propagates layout changes in both directions.
For markup, we do support it in wxGenericStaticText and several other controls, including buttons, checkboxes and wxDataViewCtrl which is quite enough for simple things like this. wxHtmlWindow is pretty nice for slightly more complicated stuff, even though it's just HTML 3.
Be the change you want to be! wxC did exist but grew unmaintained, split into several variants (I think at least wxHaskell and wxErlang had their own versions) and withered. It shouldn't be that difficult to revive it but, well, somebody does need to do it.
It's a bit funny that people don't realize that "they" are "you". wxWidgets is an old school open source project, people are supposed to contribute to it because they have their own itch to scratch.
FWIW wx has always been very friendly to new contributors, so I'd really encourage people who are annoyed by something in it to just propose changing them on wx-dev.
FWIW updating from 3.1.4 to 3.1.5 (and then to 3.2.0) should be pretty seamless.
The documentation does need work, but it's hard to find people volunteering to do it (although a few people do contribute to the docs too and this is something that is always very much appreciated). Any concrete suggestions for improvements are welcome as reports on https://trac.wxwidgets.org/newticket and, as you might have already realized by now, PRs to the docs on https://github.com/wxWidgets/wxWidgets/pulls are even more so.
Finally, asking questions (on the forum, users mailing list or SO) seems to work pretty well for most people.
I can't say much for wxPython lib, but fixing high DPI support in native controls is the main focus of 3.2.0 and things look pretty good in 3.1.5 already IMHO.
I could understand if you wrote that the layout system is not powerful enough because it's too _simple_ -- it's really just a combination of 1D box layout and 2D grid layout that can be composed -- but I really don't know what could possibly be so weird about it.
Markup support is indeed simple because we don't want to write and maintain our own CSS parser or anything like this, but you can use wxWebView to have all the browser power at your fingertips.
Putting HTML into clipboard is a one liner with wx too (just use wxHTMLDataObject as any other data object).
More could be said about the other subjects, but these ones just seem like very obvious misconceptions, so I'd like to at least leave a record here to prevent the parent post from leaving a wrong impression.
It's neither a strength (there are definitely tons of things to do) but nor is it much of a weakness because the development is quite active pretty much all the time (just look at the commit history, PR merge rate or whatever).
The main problem with 3.2.0 is that, due to our commitment to ABI compatibility for even-numbered releases, we really want to cram as many new APIs into it as possible and this keeps pushing it further and further away. If nothing catastrophic happens, it should finally be released this autumn, whether we manage to finish all the planned features (see https://trac.wxwidgets.org/wiki/Roadmap) or not, but in the meanwhile you really shouldn't hesitate to use 3.1.x, the only unstable part of it is the ABI (_not_ API).
Nice chess GUI, BTW! (although I admit that I spend what little time I have for chess exclusively on Lichess nowadays).
Among actively developed bindings, there is also wxRust at https://crates.io/crates/wxdragon