wxWidgets 3.2.0 Release Candidate

wxWidgets 3.2.0 release candidate is now available on GitHub. This release is not perfect (we might need a few more years for this), but if no catastrophic problems are discovered, it will soon officially become 3.2.0, starting the next ABI-stable release series – the first one since the release of 3.0.0 almost 9 years ago.

Please help us with testing this release by reporting any problems, especially new ones, in it, so that we could still fix them before the final 3.2.0, without waiting for another decade to do it in 3.4.0. Thanks in advance!

It might help if you explain what it is and what it does.

Looks like a module for python, etc, so unless you code/program something probably not much anyone can do to help with.

The text is a clear copy/paste from the website release info, so questionable as to whether it’s spam or not, but we can let it ride for the time being as potentially maybe someone does do GUI stuff with it. Could use GTK+ or QT for graphical stuff but then that’s most likely programming in C++, etc, rather than say Python.

Quote from wikipedia:

Sorry, I haven’t done much with the forums here so it refused to let me link to the site, wxwidgets dot org, or to include the embedded GitHub links to the sources. The announcement on the website is quite abbreviated and the wxWidgets announcement mailing list has a much more complete one with change highlights.

wxWidgets is a suite of libraries for cross-platform C++ GUI programming, similar to QT in scope, with a commercial-friendly business license (ie. you don’t have to pay to use it in a closed-source app). There are Python bindings.

The devs don’t release often (9 years since last stable version!) so this announcement is kind of unusual news. I figured maybe someone else using Rocky for their wxWidgets app would like to know about the upcoming release. I believe the current version is in EPEL, which should make it readily available to Rocky users.

While my own C++ app runs on Windows, I’ve rebuilt it on CentOS to prove that we could do it. It was quite straightforward.

I recall seeing (but haven’t written) applications that do use wxWidgets. Probably even have some installed on CentOS 7 platform (even though I don’t use them myself). Therefore, my encounters have been of type: “This application has no RPMs and requires these things. Where do I get them from?”

Seeing activity on software that has been “dormant” so long is always interesting.

As it stands, the one I see in ‘epel’ is

wxGTK3.x86_64 : GTK port of the wxWidgets GUI library

I remember now that “Audacity” (the audio editor) is one of the big open source titles that uses it.

It’s under continuous development but suffers from the devs wanting to get everything on the wishlist done before cutting a release. “The perfect is the enemy of the good.” It hasn’t been a problem for my own app because I link statically and just grab whatever the latest commit happens to be. But a lot of apps link to the system library, and distros don’t want to package a rapidly-moving target (for obvious reasons). So this new release is important for devs that use the shared libraries.

For comparison, I also use Boost and I like that it releases based on time rather than feature list. I’ve started using Boost for non-GUI parts of my app such as threading and networking.

For GUI mockup, I recommend the independent project wxFormBuilder. It lets me mock up my frames, panels, and dialogs and save them as a set of base classes. It saves to an XML project format and there’s a code generator that creates C++ source files. (I think it can also generate Python.) My business logic then goes in derived classes which hook up the event handlers for the GUI elements.

Other notable examples are FileZilla and KiCad.