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.

So, I take it we're settling for wxWidgets then? A quick cursory glance on Github shows me that the 3.2.1 branch is the one getting maintenance updates and is also compatible with XP. Seems good enough to me.

I do not think anything is settled or decided or set in stone.

So far, I have merely been pointing out various aspects that should be considered and are maybe not obvious at a first glance for people either not familiar with the code base and/or with how scalable integration with existing open source infrastructure can work.

What IMHO really should be avoided here is a situation where a new GUI gets written, but nothing would actually be achieved with regards to integrating with open source distributions and plugins (at which point the current situation with using Wine would probably be about just as good).

Another aspect that really needs to be considered is developer time. OpenMPT has currently only a very small 2 person team, and while others might join for porting to a more open source friendly platform, I would still not expect huge changes here. Trackers are a very niche software category, and tracker development is already significantly fractured into various tiny communities and teams. So, any time invested into porting should try to avoid causing a huge pile of future extra work required from the core development team.

A thing that also should be considered is actual releasability of OpenMPT while any such porting is in progress. An intermediate multi-toolkit UI might have a lot of minor quirks due to integration of different toolkits, which might not meet the usual OpenMPT release quality. This implies either moving all such development to a separate development branch (which is IMHO likely to get out-of-sync in some form or another), or it would significantly influence (read: slow down) OpenMPT update cycles. That's probably the main reason why I would prefer an approach that keeps both UIs around at the same time, which allows basing releases off of the established stable one.

"OpenMPT has currently only a very small 2 person team"
Well I am going to give learning programming another try, and have been looking into learning c++ so that I can specifically help you guys. Obviously dont hold your breath, I dont have much faith in myself, and the ONLY coding I ever used to do was html which I learned 26 years ago from internet tutorials, and which I gave up on as soon as my employers started expecting me to learn css and other back end stuff. I dont consider myself very clever is what I am saying, but hopefully I might be able to add a few of the dreams I have had for ompt one day.
What I am asking is if by learning c++ I will be ok to help / add some of my ompt dreams, or if the changes you guys are planning on here will mean I will need to learn something else. Because maybe I should learn that something else instead.

I agree with Exhale, it would be nice to know and learn what kind of technologies are suitable for the open-source nature of this project, and how to best approach those technologies. C++ as a language is just one aspect, the GUI toolkit to learn can be an entirely different beast altogether too. So having some form of guidelines or a plan on how to possible tackle any plans of cross-platform OpenMPT, that would also satisfy the approach that keeps both UIs would be nice to know.

Or, in other words. Where to start with this future project.

So there's one toolkit that hasn't been mentioned so far during the whole discussion and I'd like to know if it's a viable option. But how about throwing GTK into the mix? That one is comparable to Qt in the sense that it is very well maintained, has a C-style API and is very popular among Linux applications (and cross-platform ones as well)

It's definitely intentional at least from my side to not even mention GTK so far. ;) It might be fine on Gnome but outside of that it always feels very alien. And it's a C library, not C++, which would make development unnecessarily tedious. From what I heard they also broke compatibility between minor versions in the past, again something I'm not too thrilled about.

GTK? NO!
<https://wiki.gnome.org/Projects/GTK/Win32/MSVCCompilationOfGTKStack>

Compiling GTK on MSVC is usually considered a very difficult task. What a lot of devs do to provide Windows build is that instead they use MinGW on a Linux distro and cross-compile from there, or Github actions that if at all possible. Once setup, definitely something that could be done.

Though I heavily agree that it is very GNOME-dependent. They did break compatibility between 2 and 3 but kept some form of it during the 3 to 4 transition actually. What often breaks tends to be GNOME minor versions and its extensions instead rather than GTK as a whole but it also depends on which deps you're pulling in for your project.

Last idea I have is FLTK. Still actively maintained, supports XP even in the development branches, is C++-based and has the spirit of the 90's in it. Easier to get going for MSVC peeps on Windows than GTK as well too.

I know a few apps that use it. I believe Nestopia switched from GTK to FLTK actually and that's an active project as well.

Even worse choice IMO from a user's perspective - its look is not native to any platform, and apparently a patch to add basic accessiblity support on Windows has been sitting around for 10+ years without being merged. The last time I tried FLTK, its file browser usability was even worse than that of GTK.

Yeah, good point. Accessibility isn't exactly a good forte of most toolkits out there, other than the big and established ones at least. I haven't had issues with the file browser usability of FLTK before but the point about accessibility definitely still stands.

Now these are general toolkits and FLTK was my last idea about those. The common toolkits for use in audio apps tends to be two, JUCE and iPlug2. JUCE is probably a nonstarters because, despite its good accessibility features, it requires your code to be either GPL or commercial in order for it to be linked. iPlug2 however is licensed through zlib and has accessibility features on Windows and macOS. But I am not entirely sure if a plugin framework is good for a tracker? Would like to be enlightened on this actually

Say, I'd like to know. While the discussion surrounding the GUI toolkit is about the arguably most important component for a possible cross-platform build of OpenMPT. Are there any other libraries or components that OpenMPT depends on that makes the cross-platform build, in theory, harder to achieve? For instance. Would a Linux user be able to compile OpenMPT through MinGW to generate Windows executables instead of needing to use VS on Windows? (It seems there is MinGW support on Windows, but not on Linux is what I am asking here, as am not sure)

All other dependencies are already cross-platform. That being said, "simply" switching the GUI framework is of course not going to be the only thing that has to be done. There is Windows-specific code that is not necessarily tied to the GUI that needs to be ported as well. But that's mostly small things here and there, compared to rewriting the GUI it's negligible. As we don't even know yet where we will end up after the GUI port, it's impossible to tell at this point in time which toolchains will be usable afterwards for whatever kind of cross-compilation.

Yeah, makes sense. I would like to clarify something though as I was originally asking about compiling the current MFC codebase on Linux (You can do this with certain codebases using MinGW on Linux) and then test with Wine to check your newly compiled Windows MinGW born executable, the whole process would change with any radical GUI port though, most likely.

Well, for now I'll wait and see what the toolchain will be for the GUI framework, any announcements in short. I could help with localization once everything is set up in place (They do say Qt, for instance, has good localization features so that's something I'd be willing to try out and check how it is)

Lastly. Would it be wise to open up a forum post on this topic and see what the other users would think about a future cross-platform build? (Mostly to gather insights or experiences about that) Or too soon?

Would a Linux user be able to compile OpenMPT through MinGW to generate Windows executables instead of needing to use VS on Windows?

For MFC, no. For any future toolkit, maybe. If anything, cross-compiling to a major desktop platform will always be a second thought and not a primary concern. Supporting developmewnt natively on such a platform is much much more important.

It's a different situation for non-Desktop platforms, which, for that reason, generally tend to provide way better cross-compiling support by themselves already.

(It seems there is MinGW support on Windows, but not on Linux is what I am asking here, as am not sure)

We support building libopenmpt (not OpenMPT) with MinGW just fine, with various flavours: original MinGW, MinGW-w64 via MSYS2, and both of them also for cross-compiling from non-Windows hosts.

I was originally asking about compiling the current MFC codebase on Linux (You can do this with certain codebases using MinGW on Linux)

I honestly would call that a myth and an Urban Legend. Every couple of years, there are some forum posts somewhere by someone who hints that this should (in theory!) be possible because Visual Studio ships the MFC source code and one "could just use MinGW to compile it". I have never seen this actually done. And I doubt any such result would be legally distributable anyway.

and then test with Wine to check your newly compiled Windows MinGW born executable,

Yeah, that might work once you build with some MinGW cross-compiler, however I do not think this can in any way replace testing natively on Windows.

for now I'll wait and see what the toolchain will be for the GUI framework,

Well, only speaking for myself, but I guess Saga Musix has a similar opinion on that: Any toolkit we might choose needs to cleanly support Visual Studio (this excludes GTK). The reason is rather simple: Development turnaround times. It costs a significant amount of development time to switch between different platforms during development. If such a switch would be required while porting from MFC to SOMETOOLKIT, I really do not see this working out. Even today, I generally mostly skip testing on any other platform than the one I am currently running, even for only libopenmpt, and fix the fallout after the fact if it indeed did not work out.

I would like to clarify the 'You can do this with certain codebases' because I was practically asleep at the wheel when I wrote that, I meant that you could compile some codebases with MinGW (in the general term, as in, any github repo, including libraries). Not necessarily MFC applications, though I still went ahead and searched for answers about if such a thing is possible. To my knowledge, only one non-MSVC compiler has a licensed-copy of MFC (albeit very old, that being the DMC, or Digital Mars Compiler), and otherwise, well, not many have attempted this with MinGW on Linux. This is because MFC and company tends to use non-standard C++ features and the licensing situation makes it a very unappealing idea to most programmers, which is fair.

Fair with the toolchain being Visual Studio-based. I could only help here with localization and such since I am primarily a Linux user (or testing some features if I can compile them) but still fair. Though, to my knowledge, the cross-platform GUI toolkit with the best Visual Studio support would be Qt by far, isn't? Not to say wxWidgets has no VS support at all, but Qt has very good documentation and existing plugins that integrate well with it (example, https://www.qt.io/blog/qt-vs-tools-for-visual-studio-2022)

I've been informed of this talk surrounding moving from MFC to Qt published by the Qt group themselves
https://www.youtube.com/watch?v=-q7KAVEW45U

I would like to know what you both think about it and the points raised (manx and Saga Musix). I've read that porting from MFC to wxWidgets is also easier than Qt but comes with less powerful features and less developed tooling and integration with Visual Studio due to lack of prevalent enterprise use. I feel that defining the priority with the toolchain here would lead directly to the choice of GUI toolkit but, again, just want to hear your thoughts.

(Here is the link of what they are planning as well https://github.com/qtproject/qt-solutions/tree/master/qtwinmigrate)

Speaking of Qt. Someone came up with a leaner and meaner fork of it called LeanQt (https://github.com/rochus-keller/LeanQt) which I found through the C++ communities. It seems to address the issue raised by Saga Musix of Qt getting bloated, more commercial and less focused on older platforms while also being both leaner and faster to compile by just getting the bare essentials right. Perhaps this is a good compromise?

Speaking of Qt. Someone came up with a leaner and meaner fork of it called LeanQt

The same things applies that I already said about CopperSpice, and even more so. A single person cannot sustainably maintain a cross-platform GUI toolkit. That's really not usable for OpenMPT.

Back from scratch again then. Well, it seems the 6.xx series of Qt now has an LTS release at least (https://www.qt.io/blog/qt-6.5-lts-released) which was one of the requirements for OpenMPT here I believe (having an LTS)

As mentioned before, LTS releases are only available for commercial customers these days, meaning that at some point the LTS patches will not be available for us (or at least just with a significant delay, which I believe is what happened with the latest Qt 5.15 update).

LTS or not really does not matter at all. All I am saying is that OpenMPT will not add a single-point-of-failure when embarking on a multi-year effort to implement a new GUI. It really makes no sense at all.

Qt or wxWidgets will not disappear anytime soon.

2 or 1 person forks of Qt will.

To summarize this whole discussion (which we maybe should split into a separate issue?), there so far are really only 2.5/3 options on the table:

• wxWidgets
• Qt (with moc)
• Qt with verdigris (this has not been mentioned before, but is IMHO a viable option as it avoids the build system nightmare that is moc).

I agree on separating this discussion and making it its own issue, it has been the primary focus of discussion for the whole cross-platform OpenMPT issue.

It seems you like Qt with verdigris, why would you put that as a separate choice than Qt's moc though? It doesn't actively replace Qt, is not a fork nor a different GUI library, is just a different way for the build system. Or is it because Qt with moc is more common or has better documentation maybe?

(I am wondering if this is something that could be solved via voting. Like making a poll and present those 3 options, though I am pretty sure most end-users of OpenMPT are probably not aware of the existence of GUI libraries?)

@manx Just wanting to clarify one more thing too. Within your Qt choices, it doesn't matter if it's Qt5 or Qt6? You only said "Qt" in general but I take that to mean either of these two since they are the only ones maintained or still receiving updates one way or another

Qt5 is essentially a dying product at htis point. Yes, it still receives updates, but I know that they try to even squeeze more money out of already-paying commercial customers to add support for fast-moving target platforms like newer macOS/iOS versions. It's not viable to invest into Qt5 at this point in time.

@Saga Musix All right, so to summarize and put as addendum from what manx said, it would be:
wxWidgets
Qt6 with moc
Qt6 with verdigris

Ok, that seems fair then. Don't have any issue with these choices either