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.
As someone who has used it and preferred WX over QT for Windows based programs, the issue is not in the look and feel of the final product itself.
It's the heavy use of C style macros instead of C++ templates, mostly.
The WX C++ code looks like Microsoft Foundation Classes. I am fine with it, but for a long term project, this could discourage new people joining the project.
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?
I just thought the average diablo gamer will not know how to do that or which of these hundred files will be required. I also tried statically linking but I VisualStudio kept throwing errors at me so the easiest way to make the tool accessible for non-tech people was just uploading the dlls too
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...
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.
Macros aren't the only thing that make wxWidgets like MFC. Things like using new but not delete on objects. The method and event names. The use of DCs in paint events. Etc.
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 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.
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.
Cool to know re: 3.1.5, but I don't think I'll need to dig into it as Dolphin upstream moved to Qt, and eventually, hopefully, Slippi just mirrors that.
And yeah, I hear you on the people issue... open source is sometimes a thankless job. Overall though, great job on wxWidgets so far - I really do think it's an underappreciated project.
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.
Let me just say, you're doing a superb job with wxWidgets. Having learned and used an uncounted number of UI toolkits, wxWidgets is the least irritating I've used in a 40 year coding career. Standing ovation to you, sir.
> 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.
Yes, the wx core handles this really well. If the correct APIs are used, no or few changes to application code are necessary to handle HiDPI properly - definitely a very good aspect of wx.
> 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.
For me it remains unclear how the various sizes (MinSize, Size, BestSize and the size passed to the constructor/Create) interact with the sizer's decisions. From what I've seen a BestSize seems to more or less be treated like a MinSize, where the sizer will not continue to shrink a control if Size == BestSize.
How to correctly implement a re-flowing (where e.g. the width depends on the height, or vice versa) control is also unclear to me. wxTextCtrl does it, somehow, in a somewhat buggy way. I managed to do it but I doubt it's correct.
What I personally find weird is how sizers don't really compose - you can put sizers in sizers, but that's not what I mean: If the layout changes in a sub-sub-sub-panel, then just calling Layout() there won't usually be sufficient, you have to walk up the tree. In Qt for example I've never spend a single thought about what would change the layout and how or what needs to receive Layout calls, it's just 100 % automatic.
A combination of both of these is that I found wxScrolledWindow to be very tricky to get to work properly, even after spending a lot of time on it, I still end up with a dialog that takes a few frames to stop redrawing/changing its layout.
Another weird corner is wxCollapsiblePane.
I concede that a lot of this could be because I don't know enough about wx or because I'm too dense to understand it properly.
> Putting HTML into clipboard is a one liner with wx too (just use wxHTMLDataObject as any other data object).
Thanks, that set me on the right track to work it out. Previously I only found extremely weird/convoluted solutions and older posts suggesting that wx doesn't do it for you (google: "wx clipboard html"). But wxDataObjectComposite with a wxHTMLDataObject and wxTextDataObject indeed "just works". Perhaps something for the docs as an example?
> 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.
Well yeah, but a WebView is a pretty heavy-handed approach if you just want to make a few words bold or insert a link or something like that. Also, Qt's approach works more universally (e.g. it also applies to the labels of check/radio boxes, buttons etc., and it also lets you do things like highlight a field in red when it contains an invalid input, like people are used to nowadays).
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.
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.
The old that is strong does not wither.