F-Droid Release

[TechnologyClassroom]

Is distribution through F-Droid planned? I believe packaging in F-Droid would get the Android apk into wider audience.

[Cuperino]

It is. I haven't gotten around to it for two reasons:

1. Unlike the PC versions, the Android version is not currently ready for production use. (For Android to be production ready for tablets, first the device cannot go to sleep while it prompts and there should be a way to update QPrompt's contents and velocity remotely. For it to be ready for phones, there must be an easy way to place QPrompt's activity over the another app's activity, or a way to record video from within QPrompt.)

2. I want to sell QPrompt on Google Play before releasing it free of charge on F-Droid. Nevertheless, the Android version is currently one of the most difficult to make. If distributing on Google Play turns out to be too complicated, I might distribute on F-Droid first.

Having paid distribution options in Google Play and similar stores would help make QPrompt's development more sustainable. In any case, QPrompt should be distributed on F-Droid to cover Android users on the fringes and outside of Google's ecosystem. I'm open to anyone wanting to create and maintain the F-Droid package.

[TechnologyClassroom]

Cool! That makes sense.

I'm open to anyone wanting to create and maintain the F-Droid package.

Permission for someone else to package in F-Droid is required. This statement should help if anyone intends to help with this.

[Cuperino]

This statement should help if anyone intends to help with this.

Yes, it should help. This should also help:

Anyone can use QPrompt's name and logo trademarks in its distribution, as long as:

• They comply with the terms of the General Public License version 3
• All credits are retained
• It is provided at cost or free of charge
• No malware is added
• No additional telemetry is added
• Telemetry recipient is unmodified
• Changes are publicly disclosed
• Changes that result in the addition or removal of functionality, or differences in the program's user interface, are contributed upstream and approved for distribution prior to distribution. Upstream contributions may not always be incorporated into the main branch, but they could be approved for distribution and distribution derive from a separate public branch.

For context: At the time of writing, QPrompt's telemetry is not functional, as most of its implementation is pending development. Future versions will bring telemetry enabled, with an opt-out option upon at application start. I plan on using the information collected by telemetry to create a machine learning model that automates changes in velocity for the reader.

A few examples:

• Changes to defaults values, such as telemetry configurations and animation parameters, do not have to be contributed prior to distribution, because no functionality is removed from the software.
• Removing telemetry would result in the removal of functionality and differences in the program's user interface, thus these changes must be contributed upstream and approved for distribution prior to QPrompt's distribution.

[TechnologyClassroom]

Requiring telemetry to be enabled by default with an opt-out option will limit the ability to add QPrompt in many repositories and would also make this nonfree software.

[Cuperino]

Requiring telemetry to be enabled by default with an opt-out option will limit the ability to add QPrompt in many repositories

This is true. I may need to compromise telemetry for it to be included in some repositories.

and would also make this nonfree software

No, this is a common misconception. It would not make it nonfree software because those are my requirements to use the trademarks, not to distribute the program itself. Everyone is free to remove or replace my trademarks as part of freedoms 2 and 4:

1. The freedom to run the program as you wish, for any purpose.
2. The freedom to study how the program works, and change it so it does your computing as you wish. Access to the source code is a precondition for this.
3. The freedom to redistribute copies so you can help your neighbor.
4. The freedom to distribute copies of your modified versions to others. By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

Also, because I don't want QPrompt's reach to be diluted by forks, I'm absolutely open for there to be a branch within the project with telemetry disabled or completely removed, and for said branch to continue to make use of the trademarks.

[TechnologyClassroom]

Ok, got it. A rename to CuePrompt or anything else could have the four freedoms.

[Cuperino]

Correct. The GPL defends those 4 freedoms, so you don't really loose them with QPrompt. The limitations are there only for people who distribute the software, modified, using the original trademarks. This also gives more weight to the GPL, as a requirement to use the trademarks is to respect the terms of the license.

Trademarks are about recognizably. A way for users to know they're getting the right product and not an imitation that could be of inferior quality. Every now and then someone with no respect for other people's work comes and takes advantage of open source software, strips projects of their credits, branding, do a few changes, and starts selling them online without complying with the trademarks or licenses. This happened to us with Imaginary Teleprompter, it happened recently with OBS, and similar things have happened to several other projects, such as Kdenlive and Krita.

Had the person selling Imaginary Teleprompter at the Microsoft Store complied with the license, I wouldn't have filed a DMCA complaint to take it down. Sadly, the reason I found out about this was because they were failing to provide support, and there were very unhappy users out there. That person had stripped the trademark, but they didn't comply with the terms of the GPL 3 after 30 days of being notified. Once the 30 days were up Microsoft took it down very promptly and it never resurfaced since. By having those requirements on the trademarks, QPrompt is meant to convey a high and consistent level of quality.

My plan is to have telemetry that is respectful of the user's privacy (information would be anonymized, there would be no way to construct a user profile, and users would be able to read what they'd be sending). It would help make the program better with time, because machine learning models like the one I intend to build require a lot of data points, and because over 90% of users don't reach out to share feedback. Looking at the data would help me measure the program's use of different features. Comparing that with the verbal feedback enables better interpretation, giving both measurements and verbal feedback more meaning.

[natrius]

Maybe @IzzySoft can help here as well with more and detailed information as he is providing a big and repository for quite some apps. And as far as i know its possible to mark a release as experimental or something like that? Maybe thats worth a look as well?

[Cuperino]

Sure! Any help to package for F-Droid would be welcome.

The Android version is still not ready for production use. It could be published as experimental, I'm good with that.

Here's a quick update and recap on things I've mentioned previously on this thread:

• With regards to making QPrompt ready for production on Android: -- I've made very little progress in preventing the system from going to sleep. All of my experiments resulted in QPrompt either crashing or failing to start. -- Lately I've been working on abstracting the teleprompter components and eliminating hard dependencies on the Kirigami framework. This, among other things, will enable us to place the prompter on a separate Activity that can be overlaid on top of other apps. Nevertheless, enabling said overlay is low priority at the time. -- I haven't started working on remote control features yet, but I have them scheduled for the next feature release, which is due late January. Depending on my availability I may need to postpone remote control in favor of other features. What I prioritize will be determined in part by Patreon supporters. I will leave a link here once I make the Patreon, and other means of support, public.
• Although I still want to sell QPrompt on Google Play to help with development costs, I no longer mind releasing it free of charge on F-Droid first.
• I have not yet added telemetry to QPrompt ( as of v1.1.2), but I've decided to use KDE's KUserFeedback to implement it. Quoting from the library's page: "KUserFeedback is designed to be compliant with KDE Telemetry Policy, which forbids the usage of unique identification." The only difference between KDE Telemetry Policy and QPrompt's would be QPrompt's telemetry is to be enabled by default. An exception to this would be made specifically for F-Droid. As mentioned previously:

  I don't want QPrompt's reach to be diluted by forks, I'm absolutely open for there to be a branch within the project with telemetry disabled or completely removed.

[natrius]

1) About the 'stay awake' problem - maybe talk with the guy from https://github.com/mueller-ma/Coffee as this is the sole purpose of his app? (But, this does not work on my Xiaomi smartphone, i have to admit :D ) I guess linking https://developer.android.com/training/scheduling/wakelock for a developer is not that useful as you know it already? 2) Thats basically the same thing OSMAnd is doing. It seems to work out for them, but they are a routing app shrug 3) What i read in some apps is, that there is some kind of flavour or flag for the f-droid version. Would need to search for some other, but you might wait and see if izzy responds, he usally has a lot of tipps or suggestions espacially on this topic, if i remeber correctly.

[IzzySoft]

If you have a release build (not a debug one) which hopefully stays within the 30M limit of my repo, I could take it in there immediately. Results of my scanner look good. As for a listing with F-Droid, Qt apps are always a bit difficult to handle with the F-Droid build system, so only few managed to pass the build.

its possible to mark a release as experimental

With m repo, I can tell the updater to ignore "pre-releases" (Github allows you to mark a relase such). Another way is using different naming patterns for tags, like release-<versionName> for release tags, and pre-<versionName> for pre-releases. This works fine for F-Droid as well as for my repo.

It could be published as experimental, I'm good with that.

You can establish fastlane structures here in your repo (recommended anyway: just the text and graphics, no binaries needed), so metadata is under your control. Which a.o. means you could have a bold "DRAGONS HERE!!! in the description now – and remove it when the time comes. Gnihihi… call it "canary builds" then: once the canary disappears… :rofl:

[Cuperino]

@natrius: About the 'stay awake' problem...

Thank you natrius. I tried the Wakelock already, but the reason it did not work may not have anything to do with Android's API itself, but with how I'm connecting to it. QPrompt is not a native Android app, but a C++ app made using Qt, wrapped with native Java layer to run on Android. This means we have to go through a few layers to incorporate native functionality. Something about those layers may not be working as intended.

@IzzySoft: If you have a release build (not a debug one) which hopefully stays within the 30M limit of my repo, I could take it in there immediately.

I'm still new to mobile distribution. I've only been able to successfully make debug builds for Android using an Docker container. Here are the build instructions, scroll down for Android: https://github.com/Cuperino/QPrompt/issues/38#issuecomment-1012381925

The fact that Qt libraries must be shipped with QPrompt makes it difficult to keep its size down. The Android version already ships with less Qt components than its desktop counterparts, taking 40.5 MB as a debug package. Without debug symbols, we should be able to get it in the lower 30s, if not lower.

The other thing keeping the size high is fonts. QPrompt embeds various fonts so it can prompt text from various languages from all around the world in a consistent way across all platforms. If the fonts are not embedded into the binary, Qt cannot access them on Android. Embedding these fonts also consumes a lot of RAM while building QPrompt and is one of thing that prevents me from supporting 32 bit systems.

With m repo, I can tell the updater to ignore "pre-releases" (Github allows you to mark a relase such). Another way is using different naming patterns for tags, like release- for release tags, and pre- for pre-releases. This works fine for F-Droid as well as for my repo.

Either approach could work. I'm more inclined to use the tags because sometimes one needs small differences in package metadata between the different packages. That is at least currently the case between our AppImage and Flatpak packages. Different versions of a file called appdata.xml are needed for the AppImage to work on older systems like Ubuntu 18.04, while a newer spec must be followed to distribute the app on Flathub.

The tag could point to the same commit as the release, but although ideal this wouldn't be required.

You can establish fastlane structures here in your repo (recommended anyway: just the text and graphics, no binaries needed), so metadata is under your control. Which a.o. means you could have a bold "DRAGONS HERE!!! in the description now – and remove it when the time comes. Gnihihi… call it "canary builds" then: once the canary disappears…

Thank you, I'll look more into this later.

[IzzySoft]

Here are the build instructions

As I'm not an Android dev, I have no build environment nor due I fully understand it, sorry.

Without debug symbols, we should be able to get it in the lower 30s, if not lower.

If you manage that, give me a ping and I check. I won't argue on the byte (30M is a soft limit, the next real implication arrives at 32M APK size – but with apps tending rather to grow than to shrink, I usually do not take in apps already too close to that).

I'm more inclined to use the tags

Full ack, that's what I'd recommend, too as it gives you much more flexibility. Just think of alpha-*, beta-*, rc-* and release-* – or android-* vs. desktop-* – just to mention some examples. I've even seen OS-specific tags, so much flexibility with that.

Fastlane: great, thanks! Once I set up your app in my repo, or you apply to F-Droid, I'll check it out. Give me a ping if you need help before that. Oh, and here are some hints on formatting the full_description.txt for best results :wink:

[Cuperino]

You've got it.

I'll re-prioritize this once the remote control features are in; which are essential to improve user productivity in tablets and mobile platforms.