What APIs are missing from Harbour?

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.


Whatever is needed to have Pure Maps in the store.

Its a really good maps app and is native. And it is the only one we have.


I believe the only thing missing for Pure Maps is QtPositioning. Please correct me if I’m wrong.

1 Like

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.


A bit old now but you may have some old votes for new allowed API in harbour :


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.

  1. Secrets API.
  2. 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).


Systemd user services and timers would be amazing.

Maybe a settings entry where you can see/manipulate the schedule of timers/services


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.


Yes, it is applicable, thank you!

1 Like


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.

As for offline server, linking to libsystemd as asked for in https://github.com/sailfishos/sdk-harbour-rpmvalidator/issues/102 in 2018 :slight_smile:


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.


I believe direction was added already in 5.3.

I believe direction was added already in 5.3.

Maybe, but its still larger than 5.2 :slight_smile:

There is branch labelled 5.4 in gitlab that received some love one month ago :

So there may be some upgrade of this package in the pipeline.


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…


everything for share plugins.

tranferengine it is, i think


as mentioned before:

  • 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.

Specifically: gstreamer1.0 (already mentioned in https://github.com/sailfishos/sdk-harbour-rpmvalidator/issues/126, see also https://gitlab.com/takimata/harbour-sailstream/-/blob/master/rpm/harbour-sailstream.yaml)