Both MFC and wxWidgets are C++ bindings to the native shell library, but MFC is Windows-only while wx is cross-platform. I've been hearing that it simply takes replacing certain keywords in the source code files, which can be automated by a VSIX extension. Could the switch be possible also to aid in allowing native non-Windows releases, or is there anything stopping it? On my Linux dual-boots, I needed to jump through hoops to fix errors when enabling WINE integration.
There's more discussions going on at https://bugs.openmpt.org/view.php?id=783
Anyway, wxWidgets is not a drop-in replacement for MFC for an application as complex as OpenMPT, even if they share a lot of concepts. If it was that easy, it would have probably already been done.
Quote from: AceOfSpadesProduc100 on March 06, 2023, 03:27:53Both MFC and wxWidgets are C++ bindings to the native shell library, but MFC is Windows-only while wx is cross-platform. I've been hearing that it simply takes replacing certain keywords in the source code files, which can be automated by a VSIX extension. Could the switch be possible also to aid in allowing native non-Windows releases, or is there anything stopping it? On my Linux dual-boots, I needed to jump through hoops to fix errors when enabling WINE integration.
It's better
not to use wxWidgets, because this library doesn't render the UI by its own, unlike Qt. So you will have to deal with different problems on different platforms, especially on Linux, where the rendering is translated into GTK (which is getting worse with each release).
Sometimes you have to come to all sorts of dirty hacks (https://gist.github.com/Monsterovich/01717a44f0c7155ecb6a9d1f1544e371) to fix stuff.
tl;dr Qt is still the best option.