QPrompt's Supported Platforms

[Cuperino]

Help Wanted

Hello! Here are some ways you can help:

1. Create working RPM for the oldest currently supported version of Fedora Linux
2. Create and maintain QPrompt package for FreeBSD
3. Create and maintain QPrompt package for Haiku OS
4. Create QPrompt DMG with native binary for M1 Macs
5. Port KCoreAddons to iOS
6. Port Ki18n to iOS
7. Get the most current version of Kirigami framework 5 working on iOS

QPrompt Dependencies

QPrompt is written using the Qt Framework, which is a native cross-platform framework that supports many platforms. A full list of these platforms is available at:
https://doc.qt.io/qt-5/supported-platforms.html

Besides the Qt framework, QPrompt also uses the following libraries from the KDE community, which at the time of writing can run on the following platforms:

• Kirigami (Android FreeBSD Linux Windows iOS macOS)
• KI18n (Android FreeBSD Linux Windows macOS)
• KCoreAddons (Android, FreeBSD, Linux, Windows, macOS)
  source: https://api.kde.org/frameworks/index.html

Platform Support Goals (updated May 15, 2022)

My personal goal is that we can fully support the following platforms, on the following architectures:

• Linux (x86_64, arm64, risc-v)
• Windows (x86_64, arm64)
• macOS (x86_64, arm64)
• Android (arm64-v8a, armeabi-v7a)
• iOS / iPadOS (arm64-v8)

This means making upstream contributions so that the KI18n and KCoreAddons libraries can run on iOS. Plus help maintain Kirigami supported on both macOS and iOS. For this reasons iOS / iPad OS will likely be the last platforms to be supported.

Currently Supported Platforms (updated May 15, 2022)

At the time of writing, I'm creating the following distributable packages for the x86_64 and arm64 architectures:

• Linux (x86_64, Flatpak, Snap, AppImage; arm64, Flatpak, Snap, DEB)
• Windows (x86_64, NSIS installer)
• macOS (x86_64, DMG)
• Android (arm64-v8a, APK)

ARM Support

In relation to ARM architectures, QPrompt depends on the last open source version of Qt 5, version 5.15.2, and this limits on what distros it can run. The choice to use Qt 5.15.2 was deliberate to guarantee that it works well with the KDE libraries of today, while making it very straightforward to port QPrompt to Qt 6 when the KDE libraries are ready for it. Due to this, the Qt versions present on the current Raspberry Pi OS and the Ubuntu 18.04 LTS (used by the NVIDIA Jetson nano) are too old to compile QPrompt.

Several features would be lost in the attempt to backport, so it's simply not worth the time and effort to develop for an obsolete system. What I plan to do instead is install Fedora 34 on my Jetson nano and use that to create the first ARM64 builds. Then for the Raspberry Pi I will wait for the release of the first Raspberry Pi OS developed on top of the brand new Debian 11, and use that to make the ARMhf builds when it becomes available.

[Cuperino]

Status update for October 6, 2021,

All platforms

Some icons did not load on non Freedesktop operating systems. This is no longer the case, all icons load correctly in all builds of every system, except for Flatpak.

Linux

I've solved the low performance issues present in Flatpak builds. Snaps are working perfectly.

AppImages had the exact same permissions issues Flatpaks had, which limited performance, and additional issues with using Qt's Material Dark theme, which is required for transparent windows to work across all platforms. AppImage issues are only present when using GNU GCC compiler in Craft, Clang builds, on the other hand, don't show any issues on Craft. To my understanding this is an issue with Craft, not an issue with GCC. Nonetheless, while these problems are fixed upstream, future Linux AppImages of QPrompt will be built using Clang.

ARM on Linux

Now that both Flatpak and Snaps make proper use of hardware acceleration, I'll attempt to create a Flatpak build for armhf and arm64 architectures.

Snap relies on the kde-neon extension, which only supports the amd64 architecture, therefore, ARM Snaps are not an option unless we package Qt and KF5 inside the Snap, like it's done on Windows. This should be avoided for it drastically increases program and installer size.

AppImage won't run on ARM anytime soon due to reliance on the Craft building system and it not directly supporting ARM architecture. Our options here are to run Craft on a Docker environment setup for cross compilation, similar to how it's done for Android builds; or create the AppImage manually, without using Craft at all. In my opinion, the first approach is preferable for it makes use of the existing infrastructure, which saves time that could be spent developing other parts of the software.

Android

QPrompt can now be built for Android on armeabi-v7a and arm64-v8a architectures. arm64-v8a builds have trouble launching. armeabi-v7a have excellent performance on the Pixel 3a in which they were tested and have no trouble launching.

For QPrompt to be truly usable on tablets and phones, additional tweaks must be made to the user interface to maximize productivity. A soon to come first Android beta release will reflect these changes.

[Cuperino]

Status update for October 7, 2021,

ARM on Linux

I was able to backport QPrompt to run on the old Qt 5.12 present in Ubuntu 20.04. Running QPrompt on these libraries results in graphical problems specific to the UI, but the program functions as intended with a few modifications. On an arm64 Jetson Nano, performance is good enough to prompt smoothly on 2 screens at 1920x1080 resolution, using Qt's font renderer. Using the native font renderer increases CPU cost enough to cause small jitter occasionally. A slightly lower resolution or exclusive use of the Qt text renderer is advised on the Jetson Nano and lower spec SoC.

Attempts to build QPrompt as a Flatpak on the arm64 architecture were also successful. Because Flatpak ties into its own, up to date, containerized libraries, there were no graphical issues, and no modification was required to run QPrompt on Ubuntu 20.04 with the Flatpak. The only problem with the Flatpak on arm64 is that it is failing to connect to OpenGL for graphics acceleration, giving the following errors on application startup:

Qt Session management error: None of the authentication protocols specified are supported
libEGL warning: DRI2: failed to authenticate

This seems to be an issue between Flatpak and the Jetson nano's GPU drivers, and not an issue with QPrompt, because GPU acceleration was confirmed to work with the system libraries, and for Flatpak under the x86 architecture. I'll try getting another distro running on the Jetson nano, but I doubt much progress will be made, because driver support is limited to a few kernel versions.

[Cuperino]

Status update for October 10, 2021,

Linux AppImage

The AppImage specific issues mentioned on October 6, 2021 have all been fixed upstream. See bug report 443416 on KDE Craft for details: https://bugs.kde.org/show_bug.cgi?id=443416

ARM on Linux

Since Flatpaks work on ARM but OpenGL connection cannot be guaranteed at the moment, I proceeded to attempt the creation of distro specific Debian and RPM packages, targeting Ubuntu 21.04 and Fedora 33 distributions.

I was able to get a build made on KDE neon install and run on Ubuntu 21.04, automatically satisfying package dependencies. This means it is be possible to build a deb package for Ubuntu 21.04 arm64 and have these run on a Raspberry Pi 4 model with at least 4 GB of RAM. I still need to get an RPi 4, but I'll try getting Ubuntu 21.04 working on the Jetson nano in the meantime.

I was not able to get the RPM to install on Fedora x86 due to package conflicts with icon directory structure.

[Cuperino]

Status update for October 31, 2021,

Linux DEB on ARM64 Raspberry Pi

I was able to successfully build and install a Debian package for Ubuntu 21.04 on the Raspberry Pi 400. 4 GB of RAM are not enough to successfully compile QPrompt due to the large size of some of its assets. I ran the commands from a TTY, with no active desktop environment nor window manager active for the build to succeed.

Performance on the RPi was lower than expected, but more consistent than Imaginary Teleprompter's. OpenGL acceleration seems to be in place. I suspect the lower frame rates are due to the low specs of it's GPU. On the bright side, duplicate screens resulted in no mayor performance drop, which is impressive given how costly and CPU based this operation is in QPrompt.

[Cuperino]

Status update for November 12, 2021,

Linux DEB on ARM64 and Android builds are out

Binaries are now available for arm64 Ubuntu 21.04 and Android at:
https://github.com/Cuperino/QPrompt/releases/tag/v1.0.0-beta-005

• Raspberry Pi OS Bullseye & Ubuntu 21.04 arm64 DEB Ready for testing in production environments
• Android NOT ready for testing in production environments

[Cuperino]

Quick update: After modifying package dependencies, the Ubuntu 21.04 DEB I linked to in my previous comment now works for both the 64 bit version of Raspberry Pi OS Bullseye and Ubuntu 21.04.

There won't be support for the regular 32 bit version of Raspberry Pi OS for now, until I can figure out how to cross compile it, because the program can't be built on the system due to the limited amount of virtual RAM that can be allocated under 32 bits.

[Cuperino]

Quick update: Windows version now loads icons like all other OS, making beta-005 feature complete for the 1.0.0 release.

[Cuperino]

I'm going to close this issue now that all the platforms and architectures I wanted to support for the 1.0 release are being supported.

Android, iOS and WASM support is far away. Android is the closest but I don't expect to be able to make an iOS build before 2023 because the Kirigami framework must support Qt 6 before I can successfully port to iOS. The same is true about compiling for M1 Macs, but QPrompt works flawlessly through Rosetta.

In the meantime, I'll continue to improve the mobile experience on Android and on Linux distros for mobile devices.

[Cuperino]

I'm adding Flatpak support for amd64 and arm64 architectures. The following command will install the Flatpak for version 1.0.0 on Linux systems of either architecture that support Flatpak.

flatpak install --user https://dl.flathub.org/build-repo/72033/com.cuperino.qprompt.flatpakref

[Cuperino]

QPrompt is out and available as a Flatpak for both amd64 and arm64 architectures:

https://flathub.org/apps/details/com.cuperino.qprompt

[Cuperino]

Bugs I've reported to Craft, the software used to make QPrompt's build pipeline on Windows, macOS, Android, and Linux for the AppImage, that are currently difficulting or prohibiting QPrompt's distribution in some platforms:

1. Prohibiting Linux AppImage build with correct Qt libraries https://bugs.kde.org/show_bug.cgi?id=456455
2. Preventing Windows build process without manual intervention https://bugs.kde.org/show_bug.cgi?id=445248
3. Preventing Intel Mac build process without first time use only manual intervention https://bugs.kde.org/show_bug.cgi?id=456452
4. Prohibiting M1 Mac support https://bugs.kde.org/show_bug.cgi?id=454506

[Cuperino]

QPrompt running on Haiku OS. It has a few bugs, so I won’t be releasing this yet, but it’s amazing that it performs so well given that it’s running from a VM.
https://www.youtube.com/watch?v=HEDou12Sb4k

[eeickmeyer]

Hello!

I wanted to let you know that I have uploaded a source package of QPrompt to be officially included as part of Ubuntu's repositories! This will allow people to simply install QPrompt from either the software store for their various flavor of Ubuntu or the command line with the simple sudo apt install qprompt command. This should land in Ubuntu 23.10.

The reason I'm posting here is because I noticed your notes on the arm builds. While armhf has built in the past (I did so back in December with 1.2 on what eventually became Ubuntu 23.04), today it was a bit problematic as you can see from my logs. This shouldn't prevent inclusion as you've mentioned arm builds being somewhat experimental anyhow, but I thought I'd share my findings and data with you.

Further findings were a few issues in the overall file structure, a missing manpage, and a small issue with the .desktop file:

N:
E: qprompt: FSSTND-dir-in-usr [usr/doc/]
N: 
N:   As of policy version 3.0.0.0, Debian no longer follows the FSSTND.
N:   
N:   Instead, we use the Filesystem Hierarchy Standard (FHS).
N: 
N:   Please refer to File System Structure (Section 9.1.1) in the Debian Policy Manual and filesystem-hierarchy for
N:   details.
N: 
N:   Visibility: error
N:   Show-Always: no
N:   Check: files/hierarchy/standard
N: 
N:
W: qprompt: no-manual-page [usr/bin/qprompt]
N: 
N:   Each binary in /usr/bin, /usr/sbin, /bin, /sbin or /usr/games should have a manual page
N:   
N:   Note that though the man program has the capability to check for several program names in the NAMES section,
N:   each of these programs should have its own manual page (a symbolic link to the appropriate manual page is
N:   sufficient) because other manual page viewers such as xman or tkman don't support this.
N:   
N:   If the name of the manual page differs from the binary by case, man may be able to find it anyway; however, it
N:   is still best practice to match the exact capitalization of the executable in the manual page.
N:   
N:   If the manual pages are provided by another package on which this package depends, Lintian may not be able to
N:   determine that manual pages are available. In this case, after confirming that all binaries do have manual
N:   pages after this package and its dependencies are installed, please add a Lintian override.
N: 
N:   Please refer to Manual pages (Section 12.1) in the Debian Policy Manual for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: documentation/manual
N:   Renamed from: binary-without-manpage
N: 
N:
W: qprompt: script-not-executable [usr/share/applications/com.cuperino.qprompt.desktop]
N: 
N:   This file starts with the #! sequence that marks interpreted scripts, but it is not executable.
N:   
N:   There has been some discussion to allow such files in paths other than /usr/bin but there was ultimately no
N:   broad support for it.
N: 
N:   Please refer to Bug#368792 for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: scripts
N: 
N:
W: qprompt: unknown-locale-code LC_MESSAGES [usr/share/locale/LC_MESSAGES/]
N: 
N:   The package appears to ship locales for a language but uses an unknown locale code as a subdirectory of
N:   /usr/share/locale. This usually results in users of the intended target language not finding the locale. The
N:   language codes used in the locale directories are those from the ISO 639-1 and ISO 639-2 standards, not those
N:   usually used as TLDs (which are from the ISO 3166 standard).
N:   
N:   It is possible that the language code was mistyped or incorrectly guessed from the language's or country's
N:   name.
N: 
N:   Please refer to http://www.loc.gov/standards/iso639-2/php/code_list.php for details.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: files/locales
N: 
N:
W: qprompt: unusual-interpreter xdg-open [usr/share/applications/com.cuperino.qprompt.desktop]
N: 
N:   This package contains a script for an interpreter that is not shipped in the package and is not known to
N:   Lintian. It is possible that there is a typo or the interpreter is not executable.
N: 
N:   Visibility: warning
N:   Show-Always: no
N:   Check: scripts
N: 

The problems involving the .desktop file were easily mitigated by making a patch to remove the first line of the .desktop file, which isn't even necessary as no desktop environment uses that to execute the .desktop file anyhow. .desktop files are merely informational to indicate to the desktop environment where to find the icon, what to execute, what to name the icon, and what its long description is, and is never executable in and of itself.

The problem with /usr/share/locale/LC_MESSAGES seemed strange to me as something left-over from the build process that didn't get deleted but got picked-up by the Debhelper build system, so I did an override to delete it. Problem solved, but this might be a bug.

With the error involving /usr/doc, that one seems to be a larger problem where your build system is instaling files to /usr/doc/qprompt and not the more modern /usr/share/doc/qprompt as requried on modern Linux systems. I told the build system to move everything there, but this may be a bug worth fixing.

As far as the manpage, I did find you have a qprompt --help-all which might work to turn into a manpage, and maybe with a little more detail it would be a good fit. I could even create one downstream and include it in the future, but for now I've overridden the warning.

Anyhow, those are my findings. Excellent application, and while it's too late for me to include in Ubuntu Studio's .iso image (Feature Freeze was Thursday), I look forward to including it in the future! Either way, I do plan to announce its availability in the Ubuntu repositories. :)

[Cuperino]

The problems involving the .desktop file were easily mitigated by making a patch to remove the first line of the .desktop file, which isn't even necessary as no desktop environment uses that to execute the .desktop file anyhow. .desktop files are merely informational to indicate to the desktop environment where to find the icon, what to execute, what to name the icon, and what its long description is, and is never executable in and of itself.

Thanks for the clarification! Fixed.

The problem with /usr/share/locale/LC_MESSAGES seemed strange to me as something left-over from the build process that didn't get deleted but got picked-up by the Debhelper build system, so I did an override to delete it. Problem solved, but this might be a bug.

Fixed. The problem wasn't the line, but that I was encoding the Chinese language code using the wrong standard. I'm surprised that it worked regardless!

With the error involving /usr/doc, that one seems to be a larger problem where your build system is installing files to /usr/doc/qprompt and not the more modern /usr/share/doc/qprompt as required on modern Linux systems. I told the build system to move everything there, but this may be a bug worth fixing.

Fixed.

As far as the manpage, I did find you have a qprompt --help-all which might work to turn into a manpage, and maybe with a little more detail it would be a good fit. I could even create one downstream and include it in the future, but for now I've overridden the warning.

This might take a while... QPrompt barely has command line options, so it's never made sense to me to create a man page for it. I'll cobble up something together with minimal information.

Created an issue to tackle later.

@eeickmeyer When will the deadline for the 24.04 feature freeze be? I'd like to properly test and release QPrompt 1.2 before then.

Thank you for providing solutions in some of these findings!

[Cuperino]

@eeickmeyer A man page has been added. That was easier than I had anticipated... It is not installed in a compressed format like modern man pages, but it is placed in the correct location: /usr/share/man/man1.

Please note that all these changes have been done in the master and v1.2 branches, since these contain what will become our next release.

[Cuperino]

Hello Erich,

Alright! This is great news! I've always been a fan of Ubuntu Studio, and it was my daily driver long ago for more than a year, back in 8.10. I'll be going on a business trip over the next couple of weeks, so I won't have time to address the issues until later, but I'm looking forward to this.

At the time of writing, QPrompt 1.1.6 is the current stable version, 1.2 is in active development, with testing builds being marked with tags and the binaries being distributed over Patreon. If you ship 1.2 ahead of time, that is fine, just make sure that it is marked as a beta. 1.2 is in a stable state as of early-access-06.

My goal is to release v1.2 with more features in early January, using the most current version of KDE Frameworks 5 in the universal packages, and dropping support for Debian 11's. Having said that, it's important to state that, at the time of writing, QPrompt needs a version of Kirigami between 5.78.0 and 5.100.0 to work as intended. Version 1.2 will up the minimum compilation requirement to 5.101.0 or 5.103.0, which should be fine for anything based after Debian 12. The issue with using 5.101.0 or later is that Kirigami removed the action buttons that used to be shown at the bottom of the screen while in full screen, leaving users with no graphical way to control the prompter in that mode. It can still be controlled from the keyboard, but that may be inconvenient for new users.

With Ubuntu Studio shipping KDE Plasma these days, it probably makes more sense to ship QPrompt as a deb package, but nonetheless I would like to ask: Would it be possible to ship QPrompt as a Snap package instead? I've have had issues 5 times, where KDE changes behaviors or introduces bugs to the Kirigami framework that negatively impact the experience of QPrompt users. This sometimes requires me to re-write functionality in ways that can work for users of old and new distributions alike. With universal packaging formats, I can fix the version of KDE Frameworks used to something that I know will work across all platforms, and move to a newer version when QPrompt has been modified to work with them, or the issues with the framework have been resolved. What I would like to prevent is users from getting a buggy release, simply because I couldn't keep up with the newest KDE frameworks.

Thanks again for wanting to include QPrompt in Ubuntu Studio and the Ubuntu repositories. I look forward to making it work for both of our user bases.

Best regards,
Javier