Save Speed in Script

QPrompt
#6
  • Do you use SVG or some other scalable format, or do you use a set format (which might not be viewable for all users)?

Because screenshots of any program are raster by nature, producing an SVG isn’t a practical option for. what I do is use the PNG format. I chose it because it is compressed, lossless, and supported by all modern web browsers. Raster formats don’t scale, so, whenever possible, I will make sure that the display in which I capture the screenshot has been up-scaled by 200% or a multiple of that.

I will often take those screenshots into the GNU Image Manipulation Program (GIMP), go to Image > Mode > Indexed, and generate an optimum palette of up-to 256 colors. Reducing colors to a low number will save space at the expense of quality. When there aren’t many colors in a screenshot, I will find the smallest number of colors that produces an output that looks close to the original. If an image contains many colors (say when there’s a picture in the background), I will produce a JPEG with the following settings: 80% quality, full sub-sampling, progressive, optimized.

  • Where is the Debian build to install?

You can find the latest deb package in the aforementioned Patreon post.

Pick the build with the correct architecture for your computer. Here are the links for:

Debian, however, continues to provide outdated dependencies and will continue to do so until Debian Trixie (which recently entered its testing phase) has released. Because of that, this deb package will not work on any Debian or any derivative with KDE dependencies not older than the ones Ubuntu 25.04 provides.

It’s worth reminding that our QPrompt packages are also in testing. I’m aware that there’s at least one runtime dependency that’s not being selected and installed automatically. I don’t know yet which are those because my systems supply them (because they come with KDE Plasma). You may need to manually install the missing runtime dependencies yourself if you launch the program from other Desktop Environments and don’t have KDE Plasma installed.

#7

That last step of indexing PNGs isn’t really required tho. I do it because it saves space and thus helps the environment and the site load faster; but the compression of JPEGs and PNGs is good enough for our needs.

As to why I choose PNG and not GIF, it turns out indexed and low bit PNGs compress better than GIFs do. Both formats, however, take longer to decode (and thus longer to appear on screen) than JPEGs. So, for large sized raster images, JPEG should be preferred.

#8

You are certainly correct. I cannot install and test it. Bummer. Sorry I could not help.

sudo apt install ./QPrompt-2.0.0-EA09-x86_64-Linux.deb

Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
Note, selecting ‘qprompt’ instead of ‘./QPrompt-2.0.0-EA09-x86_64-Linux.deb’
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
qprompt : Depends: libqt6svg6 (>= 6.6.2) but 6.4.2-2 is to be installed
Depends: libqt6qmlworkerscript6 (>= 6.6.2) but it is not going to be installed
Depends: qml6-module-qt-labs-platform (>= 6.6.2) but it is not going to be installed
Depends: qml6-module-qtqml (>= 6.6.2) but it is not going to be installed
Depends: qml6-module-qtqml-models (>= 6.6.2) but it is not going to be installed
Depends: qml6-module-qtqml-statemachine (>= 6.6.2) but it is not going to be installed
Depends: qml6-module-qtquick-controls (>= 6.6.2) but it is not going to be installed
Depends: qml6-module-qtquick-dialogs (>= 6.6.2) but it is not going to be installed
Depends: qml6-module-qtquick-shapes (>= 6.6.2) but it is not going to be installed
Depends: libkf6coreaddons6 (>= 6.5.0) but it is not installable
Depends: libkirigami6 (>= 6.5.0) but it is not installable
Depends: libkf6i18n6 (>= 6.5.0) but it is not installable
Depends: libkf6crash6 (>= 6.5.0) but it is not installable
E: Unable to correct problems, you have held broken packages.

#9

No worries. Thanks for offering tho!

#10

This raises an interesting issue that is becoming a big deal with users. If programs can only run in very specific environments, then they will not have much user base available to them. That is a shame. Especially in much needed niche categories, like yours. While I know it is possible to make good quality software that runs everywhere, too many programmers seem to get hung up on issues that prevent that. I simply cannot understand that. Maybe you can explain it. I can’t.

#11

It’s a delicate balance that needs to be accomplished but it isn’t always straightforward to do so. Each OS has nuance that affects how you release software for it and what versions of the OS your app will support. Linux is easy to develop for, because the OS will satisfy dependencies for you, all you need to do is specify them. However that model stops working when your software requires libraries that are more recent than what the distribution provides. Some popular distributions, such as Debian and Linux Mint update their libraries once every two years, and when they do so they sometimes update to versions that aren’t recent. That’s what’s currently happening with the Qt framework and the KDE libraries that QPrompt depends on.

Then you may ask, why not stick to the old libraries until the new libraries are readily available on all popular distros? The answer is because porting takes time and it’s something I have to do in my spare time. I also had to write a new build pipeline because the old one kept breaking on all systems and I got tired of fixing it; that took away far more time than doing the port did. I did try to make the new build process work with both Qt 5 and 6. While I succeeded at this with a simpler application, that wasn’t the case with QPrompt. It would’ve required much duplicate code, which would’ve made the project unwieldy. Time is limited and I’ve had other things to take care of before releasing. At some point I decided to stop maintaining a Qt 5 branch and a Qt 6 branch to focus only on the Qt 6 codebase.

I should also add that Qt 5 is no longer supported by The Qt Company. That makes supporting Qt 5 software a lot more difficult, as some distribution options have become unavailable on other platforms. Linux distributions continuing to ship Qt 5 and Qt 5 version of KDE Frameworks as the primary versions of Qt and KDE software are doing a disservice to the Linux community.

I’m not worrying too much about QPrompt becoming inaccessible to Linux users (I am one of you) because this problem is only temporary. Temporary for Linux users, MacOS is a different story, which I will expand on in a few moments… Debian Trixie will probably release later this year and a new Linux Mint based on Ubuntu 26.04 will release in about a year from now. When they do, QPrompt will work on both of them, and will continue to do so for a very long time. I plan to continue developing QPrompt against the latest version of Qt; but I don’t plan on making any changes that would drop compatibility with Qt 6.8; not for as long as the popular distributions shipping that version of Qt continue to be within their regular support periods.

Certainly, there’s a one year gap, in which the Deb packages would not work in Linux Mint. That has a workaround, which is to ship the app in a universal package format, such as Snap, Flatpak or AppImage. The AppImage format isn’t working well with Qt 6, so that one is out of the picture for now. Flatpak should resolve the problem for Linux Mint users. Debian doesn’t include support for either format, but users should be able to install the dependencies for either one, Flatpak likely being the easier option to get up and running. Compared to Windows, and especially macOS, I’ve always had a good time making Snap and Flatpak packages. Due to this, I’ve left preparing them for last. In hindsight I should’ve made at least one of them sooner.

As for MacOS users, there the situation is a bit more complicated. Apple requires me to cryptographically sign binaries, or else they won’t launch. For the app to launch on most macOS versions, it must be build on the oldest macOS that apple still supports and that is a very narrow window of OSs compared to what people are using out there. To make matters worse, if I were to make builds for the AppStore, I’d be forced to use the latest XCode, leaving more users stranded. Lastly, Apple has announced that the next version of MacOS will be the last to support Intel’s CPU architecture. This will make a lot of hardware obsolete. When that version of MacOS goes out of support, I may be prevented from making QPrompt builds for Intel hardware; simply because of Apple’s code signing requirements. We’ll find out when the time comes.

So, when QPrompt v2.0 comes out, the vast majority of Linux users should be covered. I will do my best to also provide coverage to a decent range macOS users; tho I cannot promise as much to them.

#12

Thank you for providing such a good overview of your process. Much appreciated. It got me to thinking about some details upon which you may wish to expand.

The problem with when libraries aren’t included or available is nothing new. There are workarounds. In that case, why not use a universal package format for all as a simple work around?

Another question was why you stated “I may be prevented from making QPrompt builds for Intel hardware” as it makes no sense as no one can force you to do anything you don’t want.

And lastly, why make your own pipeline? Aren’t there generic ones for your language?

As always, thanks for your work.

#13

Those are valid questions.

The problem with when libraries aren’t included or available is nothing new. There are workarounds. In that case, why not use a universal package format for all as a simple work around?

I haven’t done that because universal package formats take longer to deal with than traditional packages. Flaptaks have to go through a vetting process before they’re published through Flathub, which takes away time. Snapcraft and FlatHub maintainers also constantly update application runtimes (things used to supply dependencies). That means a good chunk of the testing that I do now would have to be repeated for each runtime update and QPrompt release, adding more work. Those are the reasons why I’ve left these two formats for last.

Another alternative was to create a tarball with all dependencies included, but I couldn’t find a simple way to collect all dependencies.

Another question was why you stated “I may be prevented from making QPrompt builds for Intel hardware” as it makes no sense as no one can force you to do anything you don’t want.

I was referring to Intel Macs. Anyone could build QPrompt and use it on their own machine at any point in time, but if you bundle an app into a DMG image and put it online, modern versions of MacOS won’t let users install it unless the binary has been signed with Apple certificates. Signing binaries requires an Apple Developer account, cryptographic certificates, and Internet access. In 2026, Apple will drop support for Intel versions of macOS. If Apple wanted, they could prevent people from signing binaries for Intel versions of macOS. The servers involved could reject requests to sign binaries for Intel Macs or the certificates that would allow the apps to launch in those Macs might be revoked. These things may happen fast or they may take years, but the days of application developers supporting Intel Macs are counted.

And lastly, why make your own pipeline? Aren’t there generic ones for your language?

The new build pipeline is based on CMake and BASH. CMake is tooling which was already used to build QPrompt, I just expanded it to not only build QPrompt, but to also download and build most of it’s dependencies. (All except Qt, which is huge, so it must be downloaded separately.)

I could’ve used a package manager for C++ apps to satisfy dependencies. There are two that I can think of, but it would’ve been around the same amount of work or more to get it to work. The most difficult part isn’t to collect and build the dependencies, but to bundle everything into packages and installers. C++ has no official tooling to make packages. CMake comes with a program called CPack, which abstracts many tools for making packages, so that’s what I now use to create packages. It was very difficult to get CPack to work on Linux, macOS, and Windows simultaneously, but the results were worth the effort because, unlike the previous pipeline, this one doesn’t break while I’m not looking.

#14

Thank you once again for the good insight. So it looks like that issue regarding processors on Apple’s products has been changed for some time. They use ARM-based processors. I would think this makes them similar to Raspberry Pi’s.

Any way, what about applimage? This link seems to indicate that dependency inclusion can be fairly easy and automated:
[Packaging native binaries — AppImage documentation]

#15

They have much in common. Apple Silicon’s instruction set is a superset of what the Raspberry Pi uses, that’s been expanded with additional instructions. The hardware has also been designed to operate on larger bit quantities when it comes to memory management. This makes Apple Silicon hardware much more powerful than a Raspberry Pi while still striking towards energy efficiency. MacOS is still macOS tho, which manages packages very differently from Linux.

As I mentioned earlier in this conversation:

I tried for months, using various AppImage building tools, including experimental ones. The issue in most cases is that the tooling that collects dependencies has no way of knowing what runtime QML dependencies it needs to collect. The result is that QPrompt’s AppImage builds and runs on my computer, but then fails to work in other people’s computers. That’s not how AppImages are supposed to work. It’s difficult to identify what’s missing when the app does run on my computer. I could setup more VMs, but VMs are slow. I need to make better use of time on this project, so AppImages are halted for now.

Feel free to give them a go if you want them! Once they work, maintaining them should be easy for me. I hate dropping support for things, especially universal packaging formats. AppImage executables can be copied around and run, in practice, almost anywhere. That’s something no other universal packaging format facilitates.

In case you or anybody reading this is interested in getting AppImages to work well:

To create an AppImage (and also Deb packages), run this script within a fully populated copy of QPrompt’s source code. Get the fully populated code by running the following command… You need to have git installed on your system for it to work:

git clone --recursive https://github.com/Cuperino/QPrompt-Teleprompter.git

The aforementioned script will be located within the cloned folder. The lines pertaining AppImage building are still there in the script. You may need to update a couple that take care of downloading AppImage tooling. Feel free to change whatever you need to get it to work.

To build QPrompt, which is a pre-requirement that the script takes care of, a Qt 6 install from the official source is required. You can get that through the Qt’s installer, which can be downloaded here: Download Qt OSS: Get Qt Online Installer. At the time of writing, the setup script uses Qt version 6.8.3. Feel free to use any version 6.7 or later, simply update the DEFAULT_QT_VER variable in setup.sh accordingly.

#16

I’m going to try something else here. But first I must find the deb file for your 2.0 version. The link above has expired. Thanks.

#17

I also assume there is nothing additional to help in:
https://doc.qt.io/qt-6.9/cmake-qt5-and-qt6-compatibility.html

#18

Sorry for the inconvenience. You’ll need to log in as either a free or paid Patreon member for those links to consistently load. Sometimes I make the most recent links public for a couple of weeks or a month, but the goal is for people to use an account in order to access them, as that allows me to communicate updates to those people more easily. Early access v2.0 builds require a free membership in order to download. Information posts are all public, but requiring an account means you get emails when there’s an update. You can opt out of them if you don’t want to receive them.

Officially, access to early access betas is meant to be for paid subscribers, except when we approach a mayor release, then new builds for that release become available to free members and sometimes the public until that version is finished and released.

That said, all versions of QPrompt are licensed under the General Public License v3, so it is still free software and you’re free to share it as such. I try to make sure early access builds are of or close to the same quality as actual releases. That said, some of them are of alpha or beta quality. I try to state known bugs when it when that is the case, but it’s sometimes the community who catches them first.

As for CMake APIs, feel free to ask any questions you may have, but I will not be going back to supporting Qt 5.

We’re already using some of the new interfaces that are only available in later versions of Qt 6 for their convenience. Some of those make Qt 6.7 the minimum required version to build QPrompt v2.0. If it weren’t for those, the minimum required version would be Qt 6.4.

However, the bulk of the work for supporting Qt 5 and 6 simultaneously lies in the changes to QML APIs. There are ways to write QML and CMake that is compatible with both Qt 5 and 6, but it involves duplicating things both in CMake and QML, which is error prone and time consuming. Believe me, I didn’t just try with QPrompt and other apps, I wrote and recorded a heavily compressed video tutorial on how to accomplish this: https://www.youtube.com/shorts/zQ5hNgwuC4g

#19

Okay, thanks. I do not want to fool around with Patreon any more. I’ve had bad experiences and will not be getting involved again.

I would try to get the dependencies installed on my system, but I would have just needed a download of the latest deb file to play around with that.

Thanks anyway.

#20

It’s alright. I’ve had a couple of bad experiences with Patreon as well. I’ve been thinking of opening a Liberapay because of that… Either way, people testing QPrompt is more important than them having engagement over Patreon, so, I’ve made the link public again: https://www.patreon.com/posts/129162619

I’ve also made my recent post regarding macOS builds public as well. That includes downloads that greatly expand the amount of Apple devices that are supported: https://www.patreon.com/posts/133390125 (which is relevant to our recent conversation.)

#21

Okay, I immediately downloaded the deb version so I had it now.

Then I used Gdebi to try the install. It had a problem. I also tried QApt, but that did not work either. I used these because they are supposed to be able to satisfy dependencies.

At least I was able to verify the problem. I have 6.4.2 installed and you wanted 6.6.2. I wondered what was going on because I had both QT5 and QT6 installed. I will bet that stepping down to 6.4 would solve a lot of install problems. Of course I cannot be sure without getting past that first dependency issue.

Screenshot_2025-07-08_11-42-11 - Qprompt 2.0 with Gdebi
Screenshot_2025-07-08_11-42-11 - Qprompt 2.0 with Gdebi1280×800 65.7 KB

Screenshot_2025-07-08_11-45-33 - Qprompt 2.0 with QApt
Screenshot_2025-07-08_11-47-56 - Qprompt 2.0 dependency not missing
Screenshot_2025-07-08_11-47-56 - Qprompt 2.0 dependency not missing1280×800 103 KB

#22

I see you’re using Debian Bookworm. In addition to backporting QPrompt to work with Qt 6.4, the issue preventing us from supporting that version of Debian is that it only supplies Qt 5 versions of the KDE Frameworks that we depend on (those currently being: extra-cmake-modules, kcoreaddons, kirigami; and previously also ki18n). We’d have to create packages for those KDE libraries in addition to the package for QPrompt, for its dependencies to be satisfied. That is a time consuming process and it would have to be done on both ARM64 and x86_64 architectures. I don’t think it’s worth the time considering Debian Trixie is right around the corner.

#23

You appear to have failed to address the issue. It is not about QT5, but about QT6, which as you can see appears installed in my system. That is on Debian 12 Bookworm. So if I have QT6, why is there a problem with 6.4? It’s still QT6 isn’t it?

#24

You have Qt 6.4, it is a bit older than 6.7, which is the one that QPrompt currently requires, but it’s not too difficult to change QPrompt’s CMake code in order to make it work. That’s not the issue. The issue is Debian Bookworm doesn’t ship Qt 6 versions of the KDE Framework libraries that QPrompt depends on. Because QPrompt, in addition to depending on Qt, also has dependencies that depend on Qt. Debian Bookworm only ships Qt 5 versions of those dependencies. To work around that I’d have to create packages not only for QPrompt but for Qt 6.4 compatible versions of those dependencies as well, and that is far more work than just backporting to QPrompt to work with Qt 6.4.

#25

Out of curiosity, I looked up which versions of KDE Frameworks 6 are compatible with Qt 6.4 and it appears that none of them are. KDE Frameworks 6.1 was the oldest version I could find that indicated which version of Qt 6 it requires. The minimum required version for KDE Frameworks 6.1 is Qt 6.5.

I might be wrong, but I highly doubt that KDE Frameworks 6.0 is compatible with anything lower than Qt 6.5. Even if I’m wrong, I don’t feel comfortable backporting to use such an early version of KDE Frameworks 6.

Reference: KDE Ships Frameworks 6.1.0 - KDE Community