View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000783||OpenMPT||Feature Request||public||2016-05-09 09:29||2022-12-04 12:52|
|Target Version||OpenMPT 2.0 (very long term goals)|
|Summary||0000783: cross-platform OpenMPT|
This is a meta-issue, collecting various other issues related to making OpenMPT itself cross-platform.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
|related to||0000569||assigned||manx||Unicode strings in CSoundFile.|
|related to||0001114||new||Rewrite pattern view drawing|
|parent of||0000572||resolved||Saga Musix||Avoid non-standard language extensions for structure packing|
|parent of||0000570||resolved||manx||OpenMPT UNICODE build|
|parent of||0000771||resolved||manx||Use synchronous exception handling model in OpenMPT|
|parent of||0000782||assigned||manx||Cleanup source code directories|
|parent of||0000847||closed||manx||MSVC Clang/C2 support for libopenmpt|
|parent of||0000849||closed||manx||MSVC Clang/C2 support|
|related to||0000713||new||KeyboardHook can ultimately invoke a message loop which can cause re-entry to the hook function|
|related to||0001189||new||Multi-languages support|
|related to||0001366||acknowledged||LV2 support|
|Not all the children of this issue are yet resolved or closed.|
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.
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:
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).
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.
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?)
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.
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.
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.
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.)
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.
Ah-hah! Yes, now I get an Edit button on hover. Nice!
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).
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.
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):
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.
|2016-05-09 09:29||manx||New Issue|
|2016-05-09 09:30||manx||Relationship added||parent of 0000572|
|2016-05-09 09:31||manx||Relationship added||parent of 0000570|
|2016-05-09 09:32||manx||Relationship added||parent of 0000771|
|2016-05-09 09:32||manx||Relationship added||parent of 0000782|
|2016-08-05 11:51||manx||Relationship added||parent of 0000847|
|2016-08-06 07:36||manx||Relationship added||parent of 0000849|
|2017-08-14 18:43||Gerirish||Note Added: 0003168|
|2017-08-14 19:04||Saga Musix||Note Added: 0003169|
|2017-09-22 15:17||manx||Relationship added||related to 0000713|
|2019-01-12 08:07||manx||Relationship added||related to 0001189|
|2019-04-26 21:11||Gerirish||Note Added: 0003932|
|2019-04-26 22:10||Saga Musix||Note Added: 0003933|
|2019-04-28 18:00||Gerirish||Note Added: 0003934|
|2019-05-26 22:21||manx||Note Added: 0003949|
|2021-12-18 09:29||manx||Relationship added||related to 0000569|
|2021-12-18 09:44||manx||Relationship added||related to 0001366|
|2022-11-06 06:40||manx||Relationship added||related to 0001114|
|2022-11-14 03:17||c0d3h4x0r||Note Added: 0005370|
|2022-11-14 12:33||manx||Note Added: 0005371|
|2022-11-14 17:16||Saga Musix||Note Added: 0005372|
|2022-11-14 17:29||Saga Musix||Note Added: 0005373|
|2022-11-14 17:43||manx||Note Added: 0005374|
|2022-11-14 18:36||Saga Musix||Note Added: 0005375|
|2022-11-17 02:18||c0d3h4x0r||Note Added: 0005376|
|2022-11-21 18:21||Saga Musix||Note Added: 0005377|
|2022-11-28 09:12||manx||Note Added: 0005391|
|2022-11-28 19:47||c0d3h4x0r||Note Added: 0005392|
|2022-11-28 19:58||c0d3h4x0r||Note Added: 0005393|
|2022-11-28 20:09||manx||Note Added: 0005394|
|2022-11-28 20:13||Saga Musix||Note Added: 0005395|
|2022-12-03 23:21||c0d3h4x0r||Note Added: 0005402|
|2022-12-03 23:25||Saga Musix||Note Added: 0005403|
|2022-12-03 23:28||c0d3h4x0r||Note Added: 0005404|
|2022-12-03 23:30||c0d3h4x0r||Note Added: 0005405|
|2022-12-03 23:31||c0d3h4x0r||Note Edited: 0005392|
|2022-12-03 23:32||c0d3h4x0r||Note Edited: 0005404|
|2022-12-04 00:03||c0d3h4x0r||Note Edited: 0005404|
|2022-12-04 09:12||manx||Note Added: 0005407|
|2022-12-04 12:52||manx||Note Edited: 0005407|