[Qt5-feedback] Qt5 & QtLocation

[alex.blasche at nokia.com]

>-----Original Message-----
>On 6/8/11 2:22 PM, "ext John Layt" <johnlayt at googlemail.com> wrote:
>
>>Hi,
>>
>>I want to raise the topic of QtLocation in Qt5.  Currently QtLocation
>is
>>part
>>of QtMobility but is equally useful on the desktop and is something of
>>interest to KDE.  

Actually it is part of Qt5 now. I added it to the default build this Monday. It even has some more QML features than the Mobility version. Nevertheless there is still plenty of Mobility specific code in the current code base which will be cleaned out over the next weeks.

>>I'm wondering what the plans are with regards to
>>properly
>>supporting the desktop platforms in QtLocation?
>
>Yes, we're thinking about this. Alex should be able to give some more
>details about the state of it on desktop platforms.

We are intending to bring the API to all platforms and go as far as we can. While I cannot promise any support for any particular desktop platform there is a lot of code for desktops available already. We are very happy to take any contribution onboard.


>>There's a few areas that I think need to be addressed:
>>
>>1) The QGeoCoordinates and QGeoAddress classes should be fundamental
>data
>>types in QtCore rather than in QtLocation, so they can be used as data
>>containers and in library api without needing an entire geolocation and
>>mapping framework at compile or run time. (I also have some suggested
>api
>>changes but that's for later).
>
>I'm not sure there's enough justification to put these into QtCore, but
>I'm happy to be convinced otherwise ;-)

Indeed I'd like to hear these arguments too.

>>
>>2) QtLocation now has a GeoClue backend for MeeGo, but GeoClue runs on
>>any
>>Linux platform so the backend should be enabled for them all.
>
>Sounds like a rather simple task... :)

We tested and developed it for/on Meego but due to limited bandwidth never got around to properly testing it on other platforms. Help is very much appreciated on this front.

>>3) Are there any plans for OSX and Windows backends using their native
>>api, or
>>a fallback implementation for versions without a native api?

We don't have any immediate plans but that's mostly due to limited bandwidth and more importantly much bigger construction yards such as the changes implied by usage of OpenGL/SceneGraph/QML in Qt5.

One of the last features being added (in Mobility code base) was the ability to add a QGeoPositionInfoSource via a plug-in. This should enable arbitrary positioning backends while we focus our intention on changes mandated by Qt5's graphic stack.

>>4) Are there any plans for an OpenStretMap plugin and if not would one
>be
>>accepted?  The Ovi Maps plugin is unusable for many people due to the
>>terms of
>>use.  There are a couple of external projects to provide an OSM plugin
>>but it
>>would be far better if a single implementation was shipped in
>QtLocation.
>> I
>>think plugins for other providers like Google or Yahoo belong more in a
>>Qt
>>Addon.
>
>I thought there was at least a proof of concept available somewhere, but
>I
>might be wrong. If not I guess it's something to contribute to Qt :)

This is something we will have to tackle and I see such integrations as unavoidable (disclaimer: I believe competition is a good thing). 

The main issues I see are legal and support issues. Because we deal with services, it's a bit different from the usual "write-code-once" or "use-the-hardware-on-my-device" solutions. Almost all services impose terms and conditions which may either prevent their inclusion or at the very least create some significant legal headaches. If you go around on the web you'll have a hard time finding one without T&Cs. The support problems are along the lines of server load, changing URLs, service specific QA effort etc. I could for example imagine that OSM may get serious server load issues if integrations find a very broad usage. At the very least it needs to be managed very well.


>>5) Parts of the QtLocation api QLandmark are designed around the
>>structure of
>>Ovi services and may not work so well with other service providers, are
>>there
>>any plans to make these more generic or standards compliant?

This is actually our second construction yard and as a matter of fact QLandmark is not very suitable for Ovi services either. This is one of the lessons from Mobility which we are working on fixing now. The more commonly used term for this type of API is Places. We are currently sitting around the table to come up with a good first proposal which we hope to share very soon. We welcome every scrutiny on this front but please give us some time to complete the first draft. 

>>Obviously all these things could be contributed by the community,
>either
>>directly or as Qt Addons, but as it's a module actively maintained by
>Qt
>>knowing what Nokia's plans are would be useful before making any
>effort.

This will be entirely open. We have something similar in QtMobility already:

http://bugreports.qt.nokia.com/browse/QTMOBILITY-620

This change request list is a summary of internal and external input. At this point in time the majority of external input came from Meego and some very active individuals.
Please keep in mind that the above link is/was the "roadmap" for the Mobility version and some things are different in Qt 5 but you can expect something similar. 

>>Which also raises the question of how strategic direction for Nokia
>>maintained
>>modules like QtLocation will be decided and communicated, especially
>when
>>Nokia's interests may not agree with the wider communities interests,
>but
>>I
>>guess that's a topic for QCS?

Apart from a few sleepless nights in the location team I believe we have managed to bridge this gap quite well so far. Honestly at this stage I suggest to start sailing and see where we go. The usual collaboration points will decide how well we can channel the direction.

--
Alex