asked 2014-01-07 10:33:34 +0300
I am fairly sure that someone already is working on this ('cos a mobile phone these days without any sort of location/positioning is kinda dumb), but I'll just add this here as a tracker:
It would be very cool and useful to have both QtPositioning and QtLocation APIs available as "approved" APIs to link against, in order to enable a number of location-based apps.
answered 2014-01-07 15:17:58 +0300
We're working hard on adding support for QtPositioning. QtPositioning became stable in Qt 5.2, the Qt we ship is something between Qt 5.1 and Qt 5.2. QtLocation is not yet stable, so we can't support that at the moment until upstream Qt makes it stable. For getting the position, QtPositioning is enough (QtLocation is used for such things as maps, place search, routing and geocoding).
To get QtPositioning supported as an official API, we need to upgrade it to Qt 5.2 (as its API is only stable from then on, our current build differs a bit from Qt 5.2, as it's been taken from an earlier development version between Qt 5.1 and Qt 5.2), which we're working on at the moment, but it can take some time. If you want to see the difference of what the package we're currently shipping has and what the (API-stable) Qt 5.2 version of Qt Positioning looks like, you can do this yourself in the following way:
git clone --recursive git://github.com/mer-packages/qtlocation.git
cd qtlocation
cd upstream
git checkout v5.2.0
cd ..
diff -ru qtlocation upstream > changes_sailfish-to-qt52.patch
(a copy of that as of today is available temporarily at http://o.thp.io/tmp/2014-01-07_changes_sailfish-to-qt52.patch for your convenience)
You see, while most of these changes are internal, some QML APIs have changed, so we cannot just allow linking and using the current version of QtPositioning, as there might be conflicts.
As a temporary, not recommended workaround, you can use GeoClue via the D-Bus API directly (but check if there's a GeoClue service manager running on the current session bus, and use QtPositioning once 5.2 is out): http://www.freedesktop.org/software/geoclue/docs/
Actually, the API docs linked are for GeoCode2 - Jolla uses an older version with a quite different API, docs can be found at https://developer.gnome.org/geoclue/0.12/.
patrikf ( 2014-01-27 10:29:54 +0300 )editEdit 2: For the curious: http://parttimeelectronics.blogspot.com/2014/04/sailfishos-accessing-gps.html
ToniR ( 2014-04-19 20:28:13 +0300 )editanswered 2015-03-21 12:53:33 +0300
Qt Location won't be supported at first (because it's not yet in the list of supported modules in Qt 5), but Qt Positioning (which is supported upstream since Qt 5.2) is queued for allowing in Harbour:
https://github.com/sailfish-sdk/sdk-harbour-rpmvalidator/pull/54
UPDATE - 06. May 2015
As announced in the mailing list, we start today in Harbour to accept applications which depend on Qt Positioning.
@balta I think the QtSensors module can already be used by Jolla Store applications.
@Osmo Salomaa Looks like it will be a tech preview in Qt 5.5.
MartinK ( 2015-03-21 17:06:08 +0300 )editAsked: 2014-01-07 10:33:34 +0300
Seen: 3,119 times
Last updated: May 06 '15
If I understand correctly, the problem is that those API are not yet stable in Qt version used by Sailfish. This could cause compatibility breaks in future updates, so they are simply not allowed. This will be resolved by upgrading Qt in sailfish to newer version with stable API (hopefully soon).
koudi ( 2014-01-07 12:44:49 +0300 )editYes, this is my understanding as well. I wanted to add this topic here so we can all put nice little social pressure on Jolla to accept that they are stable ;-)
After all, both have been around since QtMobility...
Ecyrd ( 2014-01-07 12:53:35 +0300 )editis there any other possibility to obtain the position without qt5-qtdeclarative-import-positioning?
mgbler ( 2014-01-07 13:53:34 +0300 )edit