Background:
I was surprised to find mapboxgl-qml installed on my Jolla 1 phone. While OSMscout server, PoorMaps, ModRana and Laufhelden are installed, PoorMaps GL and associated libraries were not installed (at least not manually and deliberately).
Looking for the reason, I found that Laufhelden's RPM Spec-file pulls in mapboxgl-qml unconditionally.

As supposedly mapboxgl-qml was already installed for some time and I did not experience any effects, I wonder:

May mapboxgl-qml cause any negative effects on Jolla 1 phones, besides the disk space used and having another RPM installed (plus eventual dependencies)?

Can mapboxgl-qml be of any use on Jolla 1 phones (i.e. albeit slow, is this technically feasible at all)?

If not, why does it install at all (in an unsupported environment)?

These questions are aiming in two directions:

How should authors of software handle a potential dependency on mapboxgl-qml, which varies with the environment (i.e. device / installed libraries)?

Is there any chance of enabling mapboxgl-qml to run on Jolla 1 phones (no matter how slow)?

Except disk space usage, I don't see any possible side effects of having it installed on the phone if it's not used. We have debugged J1 a while ago and I might have forgotten some details, but as far as I remember, Mapboxgl was crashing itself, without bringing down the whole device. Note that some trivial maps did seem to work on J1. So, we can speculate that its possible to reduce some internal memory consumption by simplifying the schema of the map. However, its not guaranteed to work, maybe limited only to some targeted Mapboxgl versions (not work with the next release), and will probably require lots of work. Taking into account that all newer devices seem to be fine, we may just have to accept that J1 is showing its age and is going to retire with the respect of this application.

As for having it as dependency, I don't know how Laufhelden can specify them depending on the device, unless some special stripped down version will be provided without the maps.

I don't know how Laufhelden disabled the map on J1 (assuming that's your question), you probably can enable it back in the source.

This release has panning threshold enabled to avoid accidental panning of the map when you want to just click it. Implemented and proposed by @otsaloma - thank you!

This release brings us to the latest Mapbox GL Qt bindings version - 1.3.0, released two days ago. To put in perspective, its not even yet in Qt 5.11

The bumped Mapbox GL version has few bugfixes and new features. The one I was waiting for is the ability to show map styles which have missing icons in them. For example, styles based on openmaptiles have this problem. Earlier Mapbox GL versions just refused to render anything after an error - now the error is not fatal and other layers get drawn as they should. So, Cartago is shown much better now.

I haven't looked through the changes introduced lately, so cannot tell much about the new features. For interested, look through pull requests at https://github.com/mapbox/mapbox-gl-...pr+is%3Aclosed from about 8 March to end of Aug 2017 (qt-v1.1.0). [Version 1.2.0 had an annoying bug, so I skipped it].

For my surprise, OBS was fine with compiling the plugin for SFOS 2.0.5.6. I have no way to test whether it actually works. For those interested and such old SFOS version, you are welcome to test. Get packages at https://build.merproject.org/project...e:rinigus:maps .

How should authors of software handle a potential dependency on mapboxgl-qml, which varies with the environment (i.e. device / installed libraries)?

Is there any chance of enabling mapboxgl-qml to run on Jolla 1 phones (no matter how slow)?

Hi olf,
I wouldn't want to prevent mapbox-qml from installing on Jolla 1 because it does work. Only when you zoom in too much then it gets unstable and might cause the app to crash.
In the map settings of Laufhelden you can enable/disable map support.