Compatibility with Apple silicon

[Tegu]

Personally, I do not have a Mac so I cannot test nor verify the issue. Thus, I am just relaying it here.

Apparently, the .dmg releases of Melbourne for macOS do not work on newer Macs with ARM-based Apple silicon (for example, M1 or M2). The program name appears on the top left but just hangs.

Using Apple's Rosetta 2 translation did not help either. https://support.apple.com/en-us/HT211861

According to the link above, I guess the dmg releases would have to be of so called "universal" type in order to run both on Intel Macs and Apple silicon Macs. I am not sure how to package Melbourne that way.

[Iune]

Thanks for reporting this issue. 😃

Unfortunately I've also been impacted by this issue — I had recently gotten a new M1 MacBook and had run into the same issue where the existing .dmg file did not run on the new laptop. When I generate scoreboards for contests, I've been needing to run the program on my old laptop (which I'm planning on selling in the near future). Furthermore, there are several blockers on even running the base application on Apple Silicon:

• The library of PyQt 5 that the current program uses, namely PySide2, does not support Apple Silicon. Upgrading to the latest version of PyQt 6, i.e. either PySide6 or PyQt6 should solve the issue here.
• The build system I use to build and generate executables for the program, fbs, only supports up to Python 3.6 (which is EOL) and PyQt5/PySide2 in the free version. I would need to purchase a €49 one-use license (i.e. only one downloaded copy of the library) to get support for newer versions of either Python or PyQt. I don't mind necessarily purchasing a license but it would mean that others would not be able to build the application at all since only I would have the Pro copy of the library which supports Python 3.6+ and PyQt 6.

In general, building the program on Windows and macOS has gotten more difficult due to the increasingly locked down nature of these operating systems. For example, building the macOS releases requires code signing to allow end-users to run the program nowadays (requiring a $99/year Apple Developer subscription). In addition, often I can't build the program on newer versions of macOS for some time after each new OS release due to the various changes Apple likes to make between OS versions.

Testing the program is also an ongoing issue that I'm not thrilled about. Even though I'm using PyQt which is supposed to be a cross-platform library, the text rendering is operating system-specific. I've needed to add custom text scaling to account for macOS vs. Windows differences, and even then the Windows scoreboards look slightly different due to the text rendering on that operating system.

As a result, I am planning on keeping the general codebase intact, but converting the program into a web application. This is something that I've been historically hesitant to do, but a viewpoint that I've gradually moved towards over the past year or so. Before I go any further, I want to reiterate that all the existing features of the current program (most notably custom flags) would be preserved in the web application. I know that these are features used by current users of the program and I don't want to take this away as part of any transition.

• Updates to the source code or set of flags bundled with the program would be able to be pushed immediately to all users. This also removes the OS restrictions that are currently in place (ex: Windows 64-bit, Intel macOS).
• By removing the fbs build dependency, we are able to upgrade to newer versions of Python and PyQt which can be installed by anyone who clones this repository (as opposed to just me).
• The web application would target a particular OS environment (i.e. a Linux VM), so all scoreboards would be generated and rendered identically, allowing for much easier testing and validation.
• From my end, I already pay for web hosting other applications, so the main cost benefit is removing the need for the $99/year Apple Developer subscription for code signing on macOS.

I understand if anyone has any concerns with this approach but I believe it will help me support this program in the future for myself and others — please reach out to me and I can work to allay any concerns as they arise.

[Tegu]

Thank you for the thorough response!

I forgot to add later that the person actually managed to run an older version (5.0.1) after marking it safe (or something) using Macbook Air M1 and macOS Monterey 12.4. I presume macOS is actually using Rosetta behind the scenes, if PySide2 does not support M1? Apparently, the signing and notarization changes in 5.1.0 somehow affected the situation if 5.0.1 runs but 5.1.0 does not? Of course, this does not really help when developing new versions.

Replacing fbs with another build system could be an alternative but I have no idea which one. Also, it would not remove the hassle with signing and developer fees.

The plans for converting Melbourne into a web application seem reasonable especially given the license issues. I do not have any strong opinions about it. In fact, I have played with the idea earlier as well although I do like having a locally running version. Having a consistent render output definitely sounds easier, although that affects stuff like emojis as well.

(Well, the couple of times I have actually run a contest using Melbourne, I have used slightly customized version just for the sake of it.. For a normal user it might be easier to approach a web application, I guess.)