wxWidgets 3.1.5
wxwidgets.org
wxwidgets.org
I think it probably gets a bad rep when compared to "modern" UI development frameworks, however this thing is still trucking along all these years later. I'm not sure I'll need to touch 3.1.5, but it's just really cool to see it still being worked on.
I think the biggest thing the project needs though though is... documentation. Or maybe it has it, but needs some serious SEO work to make it better accessible? So much of my time was spent trying to figure out what specific feature flags meant, whether they were still valid, and so on. I've done Cocoa development for years, so I'm used to outdated/old documentation, but with wxWidgets it just felt... harder to find the right stuff. Maybe because the userbase is smaller in comparison?
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.
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.
The great thing is you can just look at the source if there's any confusion. One issue is the mildly broken nature of the macOS version (odd bugs now and then) but that's because Apple keeps changing things. It is significantly better than it was 5 years ago!
Try reading other documentation like MFC and you'll appreciate the wxWidgets documentation...
Cocoa/AppKit rarely change, and it's often one of the bigger complaints with it. Big Sur is probably the most radical version change set in years, but to say Apple "keeps changing things" for Cocoa/AppKit is not really correct.
Also, if it's not clear, I _do_ read other documentation. I still think wxWidgets needs work, and one of the devs even admitted as much in their response to me.
I am not sure if the glacial release schedule these days is a strength (it's stable, there's not much left to do), or a weakness (the project is dying). The various V3.1.x releases all say please use this release for production, even though in theory it's the even number releases that are supposed to be production worthy. Waiting for V3.2.0 (by some measure the right thing to do) would have meant waiting for many years at this point, not sure how many.
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).
((Looking into GUI toolkits for a side project, I was thinking about one of the SDL-based ones but really unsure now))
I use wx for my own stuff and also use a lot of wx-based applications. Wx is quirky and has some bugs but it's not going to go away or have a massive breaking change without warning. Its biggest weakness is the slow release schedule which leaves users waiting for a long time to access things that are critical on changing platforms (macos is a massive pain to support as the underlying system changes all the damn time). My opinion of it can be summarized as "the worst, except for all the others" so I keep using it.
I keep considering Qt whenever I start a new project and I'm still scared to use it. It's controlled by a company that is in really bad shape financially and has a history of attempting stupid things for short-term profit and screwing over customers. It's reasonable if you can manage with either just the LGPL components or if your entire project is GPL, but if not their license terms are really terrible and get worse and worse over time. They keep making changes that fuck over their paying customers. I don't feel good about using this at the moment. The KDE people have thankfully got that company by the balls with a watertight contract, and I totally trust the KDE people, but there's still plenty of damage the company can do, and every sign they will. It's really unfortunate because Qt is otherwise an excellent platform.
Multiplatform gtk is a pain. There are a few projects that successfully pull it off (Horizon EDA is a notable example) but I don't think I could manage it myself.
If you're doing a new thing you might want to consider one of the many imgui implementations (as you seem to be thinking in that direction already).
I mean, we can bitch as much as we want on what TQTC is doing with the open-source license mess, but their stock went from 8$ in 2018 to 100$ ...
http://www.nasdaqomxnordic.com/aktier/microsite?Instrument=H...
They acquired froglogic a couple days ago:
https://sdtimes.com/softwaredev/sd-times-news-digest-qt-acqu...
The imgui's are quite neat. I like the fact that building one of the demo's (with an impressive array of widgets) sort of 'just worked.' That's impressive, these days!
I suppose that's one of the reasons why Electron is so popular these days. If MacOS is constantly changing its APIs, that Microsoft can't seem to decide between classic Win32 and Modern UI, Linux that is split between Qt and GTK, plus all the mess on the mobile side.
Because OSes can't provide a consistent API, app ship with their their own OS! (a browser today is essentially an OS on top of an OS).
This. Even when targeting a single platform the developer may very well choose to use one of these frameworks just to avoid having to deal with the most horrible parts of the platform in question (and GUI's tend to be those parts.)
Having said that, for my Python projects, I am currently using Qt via PySide2 since that one worked without any problems with a simple pip installation while the other 2 gave some errors (I tried them about 2 years ago, maybe they work better now).
Another reason I currently use Qt is because I needed to do a lot of drawing and interact with these drawings on a canvas and Qt has QGraphicsView widget which is a really capable canvas widget where you can easily do transformations, interactivity with good performance and it also has a good documentation. GTK didn't have such a widget out of the box, I didn't look at wxWidgets, though, maybe that one has.
But only the old school Windows style right? I still don't get the argument because Windows itself now has like 3 different styles for their system apps themselves. There is not the "one" native style.
It's quite sad really because none of it was changed in the name of users interest.
- Only C# and C++/WinRT apps are supported
- Desktop apps support .NET 5 and C# 9, and must be packaged in an MSIX app
- No XAML Designer support
- New C++/CX apps are not supported, however, your existing apps will continue to function (please move to C++/WinRT as soon as possible)
- Unpackaged desktop deployment is not supported
- When running a desktop app using F5, make sure that you are running the packaging project. Hitting F5 on the app project will run an unpackaged app, which WinUI 3 does not yet support.
-- https://docs.microsoft.com/en-us/windows/apps/winui/winui3/
Most of long time UWP belivers just packed our stuff and are back in WPF/Win32 land.
I know in C# land WinForms was discouraged (no idea why) but what do they recommend now??
What is the "native" toolkit for modern C++ apps on Windows? I end up using wxWidgets because it is easy.
They will mention WinUI, but the team pushing for C++/WinRT killed all VS tooling support that C++/CX, so for doing WinUI with C++ you are stuck editing IDL files without any kind of VS tooling support, and also have to copy/merge the generated C++ files of the IDL ones.
> in C# land WinForms was discouraged
Portability, it seems. Not unreasonably, they're focusing on C# as a backend language in UNIX-like environments. While you can run WinForms from dotnet core, doing so adds a large chunk of libraries to your deployment and of course only works on Windows targets. I'm not sure I entirely approve of this direction, but it follows from targeting Java, and I do prefer C# to Java.
Of course, if you just want a little bit of the API, there's nothing stopping you from just p/invoking it out of user32.dll, which I did last month ...
Sounds like the direction Java took, moving JavaFX (a rather underrated GUI toolkit from what I can tell) out of the core Java standard library.
More important to me is accessibility. Does the toolkit integrate with the OS such that users can use their accessibility tools? I don't know about wx, but not all crossplatform toolkits do this consistently (or at all).
Point is: there is no such thing as native.
Depends on the desktop environment. If you use GNOME or Xfce then yes, your native toolkit is GTK. As someone pointed out over here [0], if you use KDE then your native toolkit is Qt.
(Posted from Kubuntu, incidentally. KDE is impressively polished these days.)
This is kind of a strawman, especially with wxPython. The basic widgets are native (like e.g. a button, text input, checkbox, combobox), yes, but most of the "advanced" widgets aren't (e.g. AUI, list and tree controls, which are not native on Gtk, dataview, propgrid, ...), and everything in wx.lib isn't (avoid wx.lib.agw btw.). Most of the latter category has no or limited support for Hi-DPI. Most of the latter neither feels nor looks native, to varying degrees.
Personally I find my opinion of wx has sort of evolved like an inverted parabola. It started off kinda low, because a lot of stuff has confusing names, things are done in mildly weird ways and stuff like the layout system works in mysterious ways. It reached a high point at "this is pretty ok". Kinda went downhill from there: the layout system is just a massive pita, basic things seem to be missing because they're basically not doable with that layout system (e.g. notice how there really isn't anything in wx which provides an automatically line-wrapping text/label widget), support for rich-text/HTML/markup is abysmal, the event system is a PITA, most of the advanced widgets have are barely usable from both a programmer's and a a user's point of view (wxPropertyGrid...), there is a distinct lack of APIs for system integration (try putting or getting HTML from/to the clipboard, which is a one-liner with Qt), somehow not-flicker-free drawing is still a thing in wx, and it is not taken to be granted, the menu system is the thinnest of wrappers around the lowest of common denominators; QAction/QMenu is a far superior system of interactions. There is a pattern to this; wx generally chooses to make something a "thin wrapper over lcd". Qt generally chooses to rather make a stable abstraction (works on OS 1, probably works on OS 2), and, well, abstract. Qt has Model/View, which can be a little intimidating if you use it for the first time, but it actually works really well. wx has wxListCtrl::OnGetItemText (it also has dataview since a few versions, which is in the odd place of "way more complicated than a callback, not nearly as good as Qt MV"). Qt has QAction, wx has... wxMenu::Append. wx's way of doing things definitely has advantages (for one thing, wx is far, far less code than Qt Widgets, and if the controls you are using are native, everything truly is native, though this arguably doesn't matter any more).
FWIW I probably struggled more with layouts in a single wx project in a few months than I've done in all Qt and web experience prior to that. There are just so many weird happenings which just... don't exist outside 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.
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.
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).
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.
Use wxFormBuilder if you find laying stuff out difficult.
I find the layout manager easier than Borland or MFC codebases I have had to use, that's for sure!
On which OS does dark mode work with wx? Certainly not with Windows... (which, as VZ points out, isn't wx's fault, it's just that no APIs officially exist for this - explorer.exe has dark mode, but that uses completely private, undocumented APIs).
Xamarin could be a viable choice as well.
V3.1.x is 5 years old now and it looks like they’re using semver for at least v3 releases. So I wouldn’t worry about this being an odd numbered release.
https://www.softpedia.com/get/Others/Miscellaneous/Chess-Tim...
It was many, many years ago, wayy before 2015. Not sure when. Don't have the source code.
Now there appears to be a "cracked" version on some Russian site..which is strange because I don't remember putting any kind of copy protection.
So either I totally forgot about the copy protection or someone is using my program for malware or something.
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.
Quick prototyping with Python and wx would be my typical use-case.
I found the API to be usable although the event system is bit limited in my opinion.
I even chosen it to develop a commercial app in c++(https://seamuove.com) mainly because I knew the API. Bonus is that you can produce small single exe using static linking.
Overall thanks for the effort dear wx team!