View Issue Details

IDProjectCategoryView StatusLast Update
0000783OpenMPTFeature Requestpublic2022-12-04 12:52
Reportermanx Assigned To 
PrioritylowSeverityfeatureReproducibilityN/A
Status newResolutionopen 
Target VersionOpenMPT 2.0 (very long term goals) 
Summary0000783: cross-platform OpenMPT
Description

This is a meta-issue, collecting various other issues related to making OpenMPT itself cross-platform.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Relationships

related to 0000569 assignedmanx Unicode strings in CSoundFile. 
related to 0001114 new Rewrite pattern view drawing 
parent of 0000572 resolvedSaga Musix Avoid non-standard language extensions for structure packing 
parent of 0000570 resolvedmanx OpenMPT UNICODE build 
parent of 0000771 resolvedmanx Use synchronous exception handling model in OpenMPT 
parent of 0000782 assignedmanx Cleanup source code directories 
parent of 0000847 closedmanx MSVC Clang/C2 support for libopenmpt 
parent of 0000849 closedmanx 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.

Activities

Gerirish

Gerirish

2017-08-14 18:43

reporter   ~0003168

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.

Saga Musix

Saga Musix

2017-08-14 19:04

administrator   ~0003169

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.

Gerirish

Gerirish

2019-04-26 21:11

reporter   ~0003932

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

Saga Musix

Saga Musix

2019-04-26 22:10

administrator   ~0003933

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.

Gerirish

Gerirish

2019-04-28 18:00

reporter   ~0003934

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.

manx

manx

2019-05-26 22:21

administrator   ~0003949

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

c0d3h4x0r

c0d3h4x0r

2022-11-14 03:17

reporter   ~0005370

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).

manx

manx

2022-11-14 12:33

administrator   ~0005371

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.

Saga Musix

Saga Musix

2022-11-14 17:16

administrator   ~0005372

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.

Saga Musix

Saga Musix

2022-11-14 17:29

administrator   ~0005373

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.

manx

manx

2022-11-14 17:43

administrator   ~0005374

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).

Saga Musix

Saga Musix

2022-11-14 18:36

administrator   ~0005375

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).

c0d3h4x0r

c0d3h4x0r

2022-11-17 02:18

reporter   ~0005376

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).

Saga Musix

Saga Musix

2022-11-21 18:21

administrator   ~0005377

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.

manx

manx

2022-11-28 09:12

administrator   ~0005391

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).

c0d3h4x0r

c0d3h4x0r

2022-11-28 19:47

reporter   ~0005392

Last edited: 2022-12-03 23:31

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.

c0d3h4x0r

c0d3h4x0r

2022-11-28 19:58

reporter   ~0005393

(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?)

manx

manx

2022-11-28 20:09

administrator   ~0005394

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.

Saga Musix

Saga Musix

2022-11-28 20:13

administrator   ~0005395

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.

c0d3h4x0r

c0d3h4x0r

2022-12-03 23:21

reporter   ~0005402

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?

Saga Musix

Saga Musix

2022-12-03 23:25

administrator   ~0005403

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

c0d3h4x0r

c0d3h4x0r

2022-12-03 23:28

reporter   ~0005404

Last edited: 2022-12-04 00:03

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.

c0d3h4x0r

c0d3h4x0r

2022-12-03 23:30

reporter   ~0005405

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!

manx

manx

2022-12-04 09:12

administrator   ~0005407

Last edited: 2022-12-04 12:52

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.

Issue History

Date Modified Username Field Change
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