In order to improve the attractiveness of our Jolla Store, we would like to hear from you:
What are the most important APIs which we either don’t have at all, or which are not allowed in Harbour? Or is there something else that’s blocking you from releasing your apps in our Store?
Please give your answers in the comments below.
Please note that while you can of course like each others suggestions, there will be another poll to figure out which are the most needed ones. This time we are only making a list and prioritization will happen later.
Is it possible to automate releasing updates to Harbour? I made a script for OpenRepos which I am using for deployment from CI. I have never used Harbour for my software as OpenRepos was just dead simple.
I was under the impression for the full Pure Maps experience multiple binaries and service files for socket activation were needed too. I could be wrong though.
I’d propose the following as ideas.
Secrets API.
Multiple binaries (not an API I guess).
For my own apps I’d like to see Perl executables (for GetiPlay) and background services, as well as a cron-like capability (for Contrac).
Not sure it’s applicable to this section (I’m too inexperienced and not targeting the Harbour store because of perceived limitations) but: I’m currently building my first app and I’m running into issues with there not being a unified way of giving feedback to the user of your app when there’s an error.
From looking into the dependencies expected by Pure Maps RPM, it requires QtPositioning. Rest should be OK already. With the respect of QtPositioning, please update it from 5.2 to 5.6, assuming that the license didn’t change. It is really strange that such old version is used next to Qt 5.6 still. As for why - QtPositioning 5.6 provides direction of the movement as well.
I’d like to be able to push my keyboard layouts to the Jolla Store.
It does add files to system folders, so maybe only vetted open-sources layouts (or integrate some to the main SailfishOS image) ?
In particular, someone who doesn’t enable dev mode and install apps from openrepos, can’t write in Arabic or many other languages (even though the OS supports these languages).
Posting separately. Some apps on SFOS use Mapbox GL QML plugin (https://github.com/rinigus/mapbox-gl-qml). In addition to Pure Maps, these are Amazfish and Kuri. On OpenRepos, we can just provide the plugin in a single package once and I can update the component for all apps at the same time. Such update is mainly related to the updates upstream by Mapbox GL Native lib.
In Jolla’s Store, we would need to get the plugin bundled with the app. So, we would end up with 3 plugins, possible some out of date. So, I wonder, what does it take to incorporate such dependency into the store?
FYI, plugin API has been stable from Dec 2017. Some new methods have been added, but all backwards compatible.
Interesting. I guess version 5.5 changed the license or something else is preventing branch mer-stable-on-5.6 to be merged. Or it is a hobby by Jolla engineers to go through random Qt versions, as in 5.9, 5.6, 5.4…
sharing: not only for “share plugins” but also allowing apps to share content (e.g. File Browser)
MPRIS for media players: for lockscreen and for headset buttons
custom keyboard layouts: adding them as patches is easy but an “official” way would be much better
expanding sections: I’ve written too many custom section components…
simpler releases: it is extremely tedious to release updates if you have multiple apps that should get a new release in OpenRepos, Jolla store, and Github (or any less evil forge); worst is after OS updates
not mentioned yet:
native tab bar components: ideally one like the Clock app uses, and another one with icons (like in Piepmatz, or here: https://github.com/ichthyosaurus/sf-docked-tab-bar); important: it has to adapt to horizontal layouts
custom auto completion like the Calendar app uses when adding a new event: the AutoFill component is currently in Sailfish.Silica.private and needs a custom database directory (or something…)
This is what I would like to have for my own projects:
In general: more low level access to the hardware (e.g., plain C++ APIs without Qt). Note that this probably does not make sense for the stability-focused Harbour store but only for a RPM repo (or store) featuring experimental/“not-guaranteed-to-work-in-the-next-release” applications.
