Switching from MFC to wxWidgets

Started by AceOfSpadesProduc100, March 06, 2023, 03:27:53

Previous topic - Next topic

AceOfSpadesProduc100

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.

Saga Musix

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.
» No support, bug reports, feature requests via private messages - they will not be answered. Use the forums and the issue tracker so that everyone can benefit from your post.

monsterovich

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 to fix stuff.

tl;dr Qt is still the best option.