Maybe it's a crazy idea, but merging the OpenMPT codebase with existing cross-platform trackers such as MilkyTracker or SchismTracker could also be a solution. To create a "super tracker" with benefits from both codebases so to say.

There is no point in doing this. UI is tightly coupled with the backend in OpenMPT just as it is in Milky or Schism. Both trackers would need to be modified heavily to even accomodate for the features that would need to be added. It just doesn't make sense to do this, and it is certainly not less work than porting OpenMPT's UI to a new window toolkit.

I guess cross-platform means Windows, Linux, MacOS. If so, mobile versions for Android and iOS should also be considered.

I still think a tracker for touch devices needs a fundamentally different UI approach, and we shouldn't sacrifice usability and familiarty of the desktop UI for the sake of touch devices. A touch-specific UI might happen later, but we already are very much limited in what we can do in our spare time so I would say this is a zero priority at this point.

I understand & agree with your feedback.

The reason for my comment was that DefleMask released mobile versions for Android and iOS some days ago. See http://www.deflemask.com / https://twitter.com/_Delek / https://www.chiptunecafe.com/caf/2019/4/27/deflemask-mobile-released-an-interview-with-delek for more info.

Discussion about tablet UI in the forum: https://forum.openmpt.org/index.php?topic=6169.0

I don't know if Qt supports iOS / Android, but I have extensive professional experience porting a Windows-only MFC-based app to a Qt-based cross-platform (Windows, Mac, and Linux) app. It would be really amazing to have an iOS-native version of OpenMPT so I could track on the go using my iPad Pro + Bluetooth keyboard. Happy to help out any way I can.

I disagree that a fundamentally different UI approach is needed. Using OpenMPT over Remote Desktop from my iPad Pro is already a mostly-reasonable experience. Just enable the existing desktop UI to be pinch-zoomed and drive via an Apple Pencil, mouse, or virtual mouse pointer, and it's fine. The only real downsides to using RDP to a Windows machine is network dependence, latency, and terrible sound quality (narrowband compression and artifacting performed by RDP audio streaming).

I am somewhat confused by the current Qt licensing. Even if Qt supports iOS and/or Android, it would only be useful to OpenMPT if that particularly is licensable under LGPL3.

In any case, the first step towards porting should certainly not focus on touch interfaces, but instead on conventional desktop platforms. In particular, first focusing on Windows alone would probably be the most useful, as that would allow gradually porting parts of the UI wile keeping the rest in MFC, instead of requiring an all-or-nothing approach.

Happy to help out any way I can.

Great to hear.

The first step here would probably be to figure out how to make MFC and Qt co-exist on the same Windows message loop.

The next steps would be to somewhat untangle UI logic and other logic, as that is currently somewhat intermixed in the MFC code.

The one thing that is probably really difficult to port "directly" is the pattern drawing, as that is currently implemented in (very bad) low-level GDI. See 0001114.

Qt is available for iOS and Android and I'm not aware of any licensing restrictions there. All relevant modules should be available in the open-source edition. However, as manx says this would be the last priority in any sort of multi-platform porting process. And to add to that, I don't think that this could even be an official product for at least two reasons: 1) I'm not going to pay Apple $100 a year to put OpenMPT on the app store (that's about half of our yearly infrastructure costs) and 2) Given how Apple regularly rejects applications over minor details, I absolutely doubt that they would even allow for a desktop-centric application that is not optimized for touch screens to even pass the review process. Users would have to compile the app on their own in order to run it on iDevices.

Some things to keep in mind that changed since this issue was created:

• Qt no longer offers LTS versions for open-source development. LTS versions are only available to commercial licensees.
• Qt 5 is thus effectively dead, and Qt 6 drastically increases minimum supported OS versions (e.g. Windows 7 and 8 support would be effectively dead but that shouldn't come as a surprise).
• Working with Qt on a daily basis, some of its feature creep worries me, and the quality of the core product seems to deteriorate (we have only selectively patched our Qt build at work for a period of two years because every new minor update was a new game of whack-a-mole bug hunt, with one bug being fixed but two new bugs affecting our product being introduced).

I keep thinking that with all of these changes in Qt's development, in particular the slightly worrying move away from the open-source community, wxWidgets should be considered again as an alternative. It is much more similar to MFC (for better or for worse), which might ease the porting process, and it is purely open-source unlike Qt. Apparently it even supports iOS these days but Android support appears to be only WIP.

As for keeping support for old Windows version, I certainly envision a state (or long period) where there are 2 GUIs available, MFC and Qt (or wxWidgets), which makes supporting old Windows version about as feasible as it currently is by just keeping using MFC for them. However, I would also assume the next VS version to just stop supporting anything before Windows 10, so this might not that big of a deal going forward anyway.

wxWidgets is generally hard to use cross-platform in my experience. Even the 3 main desktop platform actually vary in supported features in various detail areas, so you end up special casing them inside the wxWidgets code again (which might not be that big of a deal, but it certainly is something that would not be necessary to that extent when using Qt).

In general, I agree with the Qt concerns though (as already shown by my confusion about which parts are actually available as LGPL3).

ImGUI might well be another serious alternative nowadays (although it requires even more work and discipline to properly keep UI and logic code separate).

I don't think ImGui is going to work for us due to lack of accessibility support. Ideally we'd be able to provide the same level of accessibility as we do now without much extra work, which is a given with Qt, and as far as I can judge also with wxWidgets (on Windows at least).

Maintaining separate MFC and Qt GUIs is unsustainable/intractable.

When I helped port Tableau Desktop to macOS, the approach used was to combine the MFC and Qt message pumps and implement shim classes that enable MFC UI to host Qt UI and/or vice-versa until it was all ported over. We were able to ship multiple releases of the product where it was at various points of conversion, and customers were none the wiser.

Tableau Desktop is a very feature-rich and demanding desktop app for Windows and MacOS... we're a very heavy user of Qt. And while yes, Qt has had its share of bugs and problems, and we've sometimes had to devise our own local/private fixes until the Qt project officially fixed the problems (or simply took our fixes), I wouldn't say it's something you should avoid taking a dependency upon due to stability or quality concerns. It works well for our enterprise-class commercial product with tons of custom graphics/rendering and widgets, so I'm sure it would work just fine for OpenMPT.

Qt licensing concerns are legit, but don't sound problematic.

Apple is very good on the whole about enabling developers to validate in advance that they aren't doing anything that technically runs afoul. Then it's just a matter of adhering to App Store policies. OpenMPT isn't an emulator, can't run arbitrary code, doesn't accept in-app payments or perform in-app account creations, etc. It's just a music player and document editor. There are plenty of other trackers (such as SunVox and DefleMask Tracker) with bizarre UI that are already on the App Store without incident. The biggest logistical impediment to developing an iOS version is simply owning and using a Mac to for development :-)

Lack of LTS shouldn't be a concern as long as you're only using the GUI framework of Qt. That isn't typically the place where security vulnerabilities arise or fundamental OS incompatibilities arise. Also, just because an open-source codebase is no longer supported, that doesn't mean the code suddenly disappears or stops working. You have the code as long as you want, and you're free to bugfix it yourself (which I've done several times over the years).

Lack of LTS shouldn't be a concern as long as you're only using the GUI framework of Qt. That isn't typically the place where security vulnerabilities arise or fundamental OS incompatibilities arise

I don't care so much about security issues but rather peace of mind of not having to constantly chase after breaking changes. I see that a lot with Qt 6 recently but of course that may simple be because Qt 6 was an incomplete release from the beginning and some things were changed / added in minor updates, and they're still figuring out how to bring back some features from Qt 5. It's a much faster moving platform than Qt 5 was, and that can be a critical misfeature for a spare time project with few development resources.

Choosing the QT version would actually not be a choice for OpenMPT to make at all. That would not be dictated by what QT version is officially supported by QT upstream or by which version would be the most feature-complete on Windows.

The absolute primary concern for the QT version to target would be what is the least common denominator that is currently (or anticipated, factoring in future OpenMPT release date targets) available in major LTS distributions (that would at least imply Debian, Ubuntu LTS, Homebrew) package repositories. If we ignore that, it would make OpenMPT not any more portable to non-Windows platforms in any meaningful practical way. The QT version used on Windows can always be adapted to that least common denominator as required, because we can choose the version ourselves on Windows anyway.

Maintaining separate MFC and Qt GUIs is unsustainable/intractable.

I disagree here.

If not maintaining multiple UIs for at least considerable amount of time, it would require any QT UI to be at 100% feature parity with the MFC UI immediately for the first release. This would require significantly more development time compared to only going for something that somewhat works at first. It could be implemented in a feature branch instead of trunk to mitigate the development stall for new versions, but I somewhat doubt that would be easy either for such a huge change.

I do not think maintaining multiple UIs would be much of a problem regarding maintenance overhead. Yes, it requires factoring out not-stricly-UI-related code from the current UI code, but frankly that needs to be done anyway in order to improve code quality in the long term. Assuming that is done (which can happen at the same time as implementing a certain UI aspect in QT, thus touching the code only once), switching the UI boils down to adding mostly-simple ifdef around the 2 different UI implementations.

Integrating different text string types (which is the most prominent interaction on the type level between UI and soundlib code) is already mostly a solved problem with our encoding-type-safe string types. OpenMPT also already supports building with various different compile-time options that select very deeply integrated features in that area (mpt::ustring can be std::u8string or std::wstring, and TCHAR can be char or wchar_t, and due to our abstractions, every combination builds seamlessly; and similar abstractions to those for CString can be implemented for QString).

The QT version included by the OS is irrelevant. You just ship OpenMPT with the specific QT libraries it needs included. There's no requirement that a Linux app use the system-supplied copies/versions of all possible libraries.

(Tangent: The ability to edit previous comments here would be a huge help for those of us who are fat-fingered and/or battling autocorrect on tiny touchscreen keyboards. Also, layout of this page on mobile devices really sucks... every comment is as wide as its longest line of text; nothing word-wraps to the tiny screen width. Are these things anyone here can do anything about? Should I file a separate issue or two on them?)

The QT version includes by the OS is irrelevant. You just ship OpenMPT with the specific QT libraries it needs included. There's no requirement that a Linux app use the system-supplied copies/versions of all possibly libraries.

Well, no.

Then we would have to ship 100 packages for all 100 distributions available, because no distribution can be bothered to ship the one single custom QT version that OpenMPT requires. This does not scale at all.

If we want users (and distributions) to be able to build OpenMPT themselves, working correctly with the distro-provided library versions is absolutely essential. libopenmpt would have had no distribution adoption at all if we would only have supported the latest released versions of our dependencies and not cared about what versions are actually available in practice.

Also, providing our own built dependency libraries will lead to symbol conflicts with system-installed plugins.

In any case, this is in the end a minor point, and nothing that needs to be discussed right now, I think.

Tangent: The ability to edit previous comments here would be a huge help for those of us who are fat-fingered and/or battling autocorrect on tiny touchscreen keyboards

You can... but I think the "tiny touch screen" is the issue here: The edit button only shows up on hovering your comment, and that's of course not a thing on touchscreens. Unfortunately there hasn't been any movement in the relvant Mantis ticket: https://mantisbt.org/bugs/view.php?id=23565

Anyway, I agree that technicalities about Qt version can be saved for later. I just wanted to raise that concern because it also directly impacts Linux distributions these days (they can no longer stick to a Qt LTS version because it no longer exists) and thus also directly impacts with what kind of Qt versions we have to support.

You can... but I think the "tiny touch screen" is the issue here: The edit button only shows up on hovering your comment

Hovering over my comment (in either Edge, Chrome, or Firefox on my Windows 10 desktop PC) does not show any kind of edit button. What are you referring to?

Can you try again? I think the threshold for which user group the feature is available was too high by default.

Then we would have to ship 100 packages for all 100 distributions available, because no distribution can be bothered to ship the one single custom QT version that OpenMPT requires.

What are you talking about?

There would be zero dependency upon the system-provided Qt shared libraries. OpenMPT would come with its own copy of the exact version of the Qt libraries that it needs. In fact, OpenMPT could just link against static Qt libraries, and then it wouldn't even need to redistribute any Qt shared libraries.

If you're worried about transitive dependencies by Qt upon other system-provided shared libraries, that's also a non-issue; you can build Qt using static libraries to produce static Qt libraries. (See https://stackoverflow.com/questions/1011197/qt-static-linking-and-deployment, for example.)

If we want users (and distributions) to be able to build OpenMPT themselves, working correctly with the distro-provided library versions is absolutely essential.

Why? Anyone can download any version of the Qt sources and build them, regardless of what version of Qt a given Linux distro may use. They have nothing to do with each other.

Can you try again? I think the threshold for which user group the feature is available was too high by default.

Ah-hah! Yes, now I get an Edit button on hover. Nice!

packageability:

There would be zero dependency upon the system-provided Qt shared libraries.

Depending on specific versions of libraries and explicitly not using the packages provided by the distribution would be a policy violation for a lot of major Linux distrbutions, which implies that such an OpenMPT would then not be packageable for that distribution. Distributions only make exceptions to that rule for very high-profile packages (Which basically means Firefox and Chromium, and nothing else).

legality:

OpenMPT could just link against static Qt libraries, and then it wouldn't even need to redistribute any Qt shared libraries.

No. Open-source QT is licensed under the LGPL3. Statically linking LGPL3 libraries implies the resulting binary and the source that generated that binary are also required to be LGPL3-licensed. While anyone maybe may (to some extent) re-license and then distribute OpenMPT under LGPL3 (as our BSD3 license is compatible with the LGPL and allows that to a certain extent), OpenMPT itself will not at all go in that direction. OpenMPT currently already uses 3 LGPL2-licensed libraries (lame, mpg123, soundtouch) which we are also only ever dynamically linking, for exactly the same reason. OpenMPT will never statically link LGPL code.

ease-of-use:

Why? Anyone can download any version of the Qt sources and build them, regardless of what version of Qt a given Linux distro may use. They have nothing to do with each other.

Have you ever tried building and installing software on Linux that required a specific framework version (QT or any other big one) inluding all of its dependencies without conflicting with anything provided by the distribution itself? That's not something you can expect any normal user (or even developer) to be able to achieve. Sandboxed applications (like Snap, AppImage, FlatPak, ...) can do that, but it prohibits integration with the huge library of open-source audio plugins that are already packaged by distributions (see below).

integration with distribution-provided plugins and ELF symbol conflicts:

Assuming what you are suggesting would be feasible, it would in all cases result in ELF symbol conflicts in, for example, the following situation ("->": links/loads):

• OpenMPT -> openmpt-libqt-vN
• openmpt-libqt-vN -> openmpt-libsomething-vM
• OpenMPT -> distribution-pluginfoo-vO
• distribution-pluginfoo-vO -> distribution-libsomething-vP

Notice that this results in 2 different versions of libsomething ending up in the same process image. ELF dynamic symbols are loaded into a single global process-wide symbol table, which would result in the process potentially picking up random combinations of functions from that library in version vM or vP. ELF symbol versioning may solve this, but it is rarely used in practice for anything but core toolchain libraries (glibc, libgcc, libstdc++). Notice that this is fundamentally different from how Windows PE handles symbols in shared libraries, where accessing the symbol basically implies specifying the shared library name as well.

So, the net result of building OpenMPT with its dependencies not coming from distribution packages would result in an OpenMPT that would be unable to load any plugin (or even library) from the distribution. That's not useful.
Distributions and their fixed package versions exist specifically to avoid such conflicts and enforce this by their package dependency and conflict mechanisms. Opting-out of using distribution packages implies having to do all that work oneselves.

Just a question... I have started trying to migrate over to linux, and I installed the AUR OMPT on my Manjaro KDE Plasma...
64bit vsts work perfect, but 32bit vsts the interface of the vst vanishes if I try to edit them... who did this version of ompt so I can tell him or her? This is a big frustration to me because most of my vsts are 32bit, and as much as I would love to migrate over to linux fully this glitch would mean I have to use a VM to make music in modplug... Btw I am very impressed that they managed to get it working at all, but I need my 32bit plugins, dblue glitch only comes in 32bit for example.

@Exhale please report a separate issue for things like that. I would really prefer to keep this issue clean of unrelated topics. see 0001270

Depending on specific versions of libraries and explicitly not using the packages provided by the distribution would be a policy violation for a lot of major Linux distributions. [...] Distributions only make exceptions to that rule for very high-profile packages (Which basically means Firefox and Chromium, and nothing else).

Yeah, Linux app distribution is a total dumpster fire. Even Linus himself has said so in interviews. In the end, the only thing that may eventually fix it would be some sort of dockerized/containerized form of an app package... and that is still nowhere close to a reality or standard, afaik.

such an OpenMPT would then not be packageable for that distribution

Sure it would. It just wouldn't be included in the distro's default package manager repositories. The user would simply have to go download and install a binary package from a web site or manually add an extra package manager repo. Not a big deal.

No. Open-source QT is licensed under the LGPL3. Statically linking LGPL3 libraries implies the resulting binary and the source that generated that binary are also required to be LGPL3-licensed.[/quote]

Fair point -- and not one I ever had to concern myself with. All my Qt development experience was done for my employer, under the umbrella of a commercial use license.

Have you ever tried building and installing software on Linux that required a specific framework version (QT or any other big one) including all of its dependencies without conflicting with anything provided by the distribution itself?

Yes -- that's exactly how we build and distribute our commercial products for Linux.

That's not something you can expect any normal user (or even developer) to be able to achieve.

Which is why we do that for our customers by distributing our app as a nice pre-built binary package.

Sandboxed applications (like Snap, AppImage, FlatPak, ...) can do that, but it prohibits integration with the huge library of open-source audio plugins that are already packaged by distributions [...] the net result of building OpenMPT with its dependencies not coming from distribution packages would result in an OpenMPT that would be unable to load any plugin (or even library) from the distribution. That's not useful.

Another fair point. This didn't occur to me because I've never used VSTs/plugins with any audio software under Linux. I stick to Windows for my personal usage, exactly to avoid these kinds of unnecessary hassles.

If not maintaining multiple UIs for at least considerable amount of time, it would require any QT UI to be at 100% feature parity with the MFC UI immediately for the first release.

Untrue. You create shim UI classes and combine the MFC and Qt event loops, and then you can gradually port pieces of the UI over incrementally without users even knowing.

I do not think maintaining multiple UIs would be much of a problem regarding maintenance overhead.

Have you ever done it? Because I have. And I can tell you for a fact that it's an unsustainable nightmare. You end up having to do twice the work to maintain two completely different implementations, each with their own unique sets of quirks and bugs. Always better to maintain and work on only a single implementation that works everywhere.

switching the UI boils down to adding mostly-simple ifdef around the 2 different UI implementations.

That is a really terrible approach, because it creates a bunch of extra maintenance burden, an opportunity for things to drift wildly out of sync, and divides your personnel into "the ones who know the Qt side" and "the ones who know the MFC side".

We only managed to port our huge commercial MFC desktop app to a cross-platform Qt desktop app while continuing to crank out releases along that multi-year journey because we used the shimming approach I described above and maintained one implementation of the UI, until it was finally all ported over. And even that was a huge onion-peeling project that entailed hunting down and fixing all kinds of unexpected bugs along the way, due to the many differences between MFC and Qt under the hood. While they utilize many of the same concepts, the way they deal with dialog resource templates and layout is very different and requires a lot of work to port.

So just wanted to hop in and join on the discussions about the toolkit that will be used for a future cross-platform OpenMPT. It seems there's the choice of going with wxWidgets and Qt. I'd like to mention CopperSpice to the list as well since they seem to be using some rather recent C++ features and is also actively maintained from what I'm seeing: https://github.com/copperspice/copperspice

I have no particular preference in this discussion actually. I do believe that there's more tooling and developer support for Qt out there than those that can handle CopperSpice or wxWidgets, but that's just one factor to consider when licensing is also among the topics to discuss. Another possible alternative could be to use modern .NET and write a C# based frontend for the tracker as well (Mixing, for instance, Avalonia for the UI tasks with C++ for the backend). Avalonia is MIT-licensed and runs well on Windows, macOS and Linux, though that would also require reworking the tracker internals, maybe add SDL2 within the deps and more to get it working.

There's no obvious solution to what to choose here. If the aim was to attract contributors and also have its license satisfied, Avalonia/C# seems like a very good choice here. But this would add a dependency towards .NET compilers provided by Microsoft and that's something that the team would have to think about well before committing to do so.

Hope you all can find some way to solve this first step!

Cheers.

I don't think the programming language is what's keeping people from joining tracker development in general (lack of developers is a very general theme across all trackers, no matter what language they are written in). For a niche software, this is not unexpected. That being said, I have no interest in rewriting OpenMPT UI in C#.

CopperSpice seems to have evolved a lot since the last time I had heard of it, it may indeed be worth investigating.

I personally vouch for CopperSpice then, it's been featured regularly across many recent C++ talks and they have taken advantage of its more modern versions to improve the toolkit. Their YT channel is very insightful too https://www.youtube.com/@CopperSpice/videos

I am very strongly opposed to CopperSpice.

While it has the advantage of modernizing Qt, I very much doubt that any major cross-platform GUI toolkit can be sustainably maintained by only 2 people (<https://github.com/copperspice/copperspice/graphs/contributors>). The amount of presence that CopperSpice shows in C++ conferences is way over-representing what they actually achieved. As I see it, so far, they have primarily shown to be good at marketing, and that's about it. Given the amount of compatibility bitrot that can be seen in both, Qt, and wxWidgets, it is absolutely guaranteed that it will be multiple orders of magnitude worse in CopperSpice.

Hmm, fair enough. It did seemed impressive since they were often at C++ talks and conventions and were promoted quite a bit in the C++ communities, but compatibility bitrot is something I haven't seen them addressing much I believe, mostly that the libraries require the use of a C++17 compiler, and looking at previous posts and requirements for OpenMPT. If maintaining older Windows builds is a desired trait, then, yeah, I can see it being an issue with CopperSpice in particular.

From here. The best I can think of is the already suggested option for wxWidgets. It does not have the cadence of releases that Qt6 has and is rather stable, but still coming out with new solid releases so far, they even added Wayland support and all for 3.2.0 among other things (macOS dark mode, Apple silicon support, etc.) and is friendly licensing-wise.

Though I would like to know more what would be the pros and cons of using wxWidgets then, since that seems to be the best option with good compatibility for older OSes too like Windows 7 and XP.

Looking purely at user-observable effects, some of the advantages / disadvantages are:

• wxWidgets is lightweight and supports older OSes, as mentioned.
• Qt has better styling support, which would help with some of the traditional complaints about OpenMPT's look and feel (people could easily re-skin the entire application). wxWidgets is currently working on adding dark mode support for Win32, so the most important type of complaint would actually also be addressed by wxWidgets (although not yet in the current stable release).
• wxWidgets is closer to OS APIs, which can be an advantage and disadvantage the same time. For example, with MFC it's currently difficult to impossible to implement 0000687 because adding hundreds of widgets to the General tab both exhausts the number of available GDI handles way too quickly, and it is very slow. Qt might have an advantage here since it doesn't create GDI widgets (it just uses OS styles for drawing them). wxWidgets might pose the same problems as MFC in this particular regard but I have not verified that yet. It's definitely one thing to consider before making a final choice, since this is a long-standing feature request
• Qt provides good localization and accessibility facilities.

Qt is made by a company whose primary source of income is commercial Qt development licenses. It is also already firmly established within the commercial and open-source ecosystems. As such, its future is not subject to the usual risks of open-source projects becoming abandonware when their creators disappear or when a company decides it's not a big enough part of their business anymore. And they have the development resources needed to keep maintaining it.

I've heard one person in this thread mention non-specific concerns about "bit rot" with Qt. Those concerns may or may not be legitimate at this moment in time. Regardless, the Qt company is strongly financially incentivized to address bugs and shortcomings over time, because that's the business they are in.

I am not necessarily a believer that because a company is developing the software it means that it'll have security for the longest term. I mean, it isn't entirely unlikely or impossible that the Qt company may reach a bad point, financially speaking, and then the community would be left in charge of Qt now. (Just a what if, not a certainty, but it could happen)

What I wanted to know were the pros and cons of each toolkit in the context that OpenMPT needs. Well, and from here, I can see that there's going to be quite a few different views for this. Choosing Qt6 (I am going to assume that the discussion will surround Qt6) means sacrificing most Windows pre-10 support, and while I don't have a survey on hand about the majority that uses OpenMPT on Windows, I am sure a non-trivial amount of them do use them on older versions of it.

From my point of view, I believe maintaining two versions of OpenMPT to handle this usecase of older Windows users may work at first but it'll be clear that the port to another toolkit means that version will have more features and obvious improvements in comparison to the original one, so offering 'cross platform build' and 'MFC build' may have the users of the latter mostly migrating to the former while the other Windows users would be left with, well, the original one, whether or not handling two codebases to satisfy everyone is a good idea escapes me, depends on how the lead developers feel about it.

However, choosing Qt6 means better styling and customization out of the box than the original, and I am a huge proponent of customization here. Newer apps are coming with the ability to let you choose colorschemes (even if some of them only let you pick dark or light colorschemes, others let you go wild with colorschemes) and giving the users that ability is very important now. Not only for aesthetic purposes but also for practical ones, users could set up high-contrast colorschemes or visual cues for the impaired and that would be a boon for OpenMPT to have. This + Qt allowing to get a fix for 0000687 (https://bugs.openmpt.org/view.php?id=687) seems like a great step forward all things taken to a balance.

Truth be told, I think both toolkits are workable on their own, but if concerns about immediate look-and-feel, accessibility features and more is needed, I think Qt would have the edge here simply because of its faster development pace and documented features, as well as really good tooling (as Saga Musix mentioned that wxWindows has a native dark mode on Windows but only in master, which means waiting additional time to get that on a stable release, and then for it to documented, which doubles that time further). But the discussion around Qt I believe had to come to a rough halt due to licensing concerns. I believe Qt was LGPLv3 last I heard though?

Then. What are the biggest showstoppers for each? If there are any additional cons for wxWindows or Qt that have yet to be mentioned that would be good to know.

Sure it would. It just wouldn't be included in the distro's default package manager repositories. The user would simply have to go download and install a binary package from a web site or manually add an extra package manager repo. Not a big deal.

That is somewhat ridiculous: What if every project would do that? Take 10 major Linux distributions, each with about 10000 packages, then take 1 million Linux users. You may run the numbers of how much work your approach creates yourself.

Each application using its own custom package repository for each distribution does not scale and is not the way open source software distribution works. I maybe could maintain a deb package mayself, but for other distributions that I do not even use? No way. I can easily maintain 3 GUIs in the time required to learn 100 different packaging and repository mechanisms.

Yes -- that's exactly how we build and distribute our commercial products for Linux.

And that may well be the point where you need to start thinking differently. An approach for a commercial application can be very different compared to the approach required for an open source project which needs to be compatible with existing infrastructure.

I stick to Windows for my personal usage, exactly to avoid these kinds of unnecessary hassles.

See, there is 0 hassle for users (i.e. even less than on Windows) when the plugin host and the plugin itself are both packaged in the same official distribution repository, so this is the goal. Anything else makes no sense from a work scalability point of view.

Untrue. You create shim UI classes and combine the MFC and Qt event loops, and then you can gradually port pieces of the UI over incrementally without users even knowing.

... at that point, everything you need to do is to keep the old implementaion around, and we arrive at my suggestion.

Also note that a gradual approach is not that simple as it might have been for the application you have experience with. OpenMPT makes heavy use of the document-multi-view MDI functionality in MFC, which I imagine being basically a blocker for any kind of gradual porting to any other toolkit. And that's about 80% of the OpenMPT GUI.

That is a really terrible approach, because it creates a bunch of extra maintenance burden

It's factor of less than 2. Compare that to the factor of 100 you have just been suggesting for OpenMPT packaging a custom repository for 100 different Linux distributions.

an opportunity for things to drift wildly out of sync, and divides your personnel into "the ones who know the Qt side" and "the ones who know the MFC side".

There is not even anything wrong with different UIs exposing different kind of functionality or taking different approaches. It also encourages factoring out UI from logic code, which is a huge opportunity for general code quality improvement (and badly needed for OpenMPT anyway).

We only managed to port our huge commercial MFC desktop app to a cross-platform Qt desktop app while continuing to crank out releases along that multi-year journey because we used the shimming approach I described above and maintained one implementation of the UI, until it was finally all ported over. And even that was a huge onion-peeling project that entailed hunting down and fixing all kinds of unexpected bugs along the way, due to the many differences between MFC and Qt under the hood.

Only because one approach happened to work for you, this does not imply that other approaches will not work. I myself have worked on multiple projects that have different frontend implementations (for various reasons: in-progress porting, vastly different platforms/environments, ...). If done correctly and carfully, this does not result in a huge explosion in maintenance overhead. Applied to OpenMPT, it might even be simpler to not gradually port with a multi-toolkit UI during the process, because you not only have to make the event loop work for MFC and QT, but for MFC and QT and VST.

while I don't have a survey on hand about the majority that uses OpenMPT on Windows, I am sure a non-trivial amount of them do use them on older versions of it

See <https://buildbot.openmpt.org/statistics/> and <https://buildbot.openmpt.org/statistics/old/>, but expect these statistics to be skewed away from older systems for multiple reasons:

• 1.30 RETRO builds do not send any information at all
• users with EOL-systems are somewhat less likely to connect them to the internet

Thus, these numbers probably show a lower bound for users using older systems.

You clearly have your mind made up already. I wish you luck with your approach.