[Marble-devel] QtMobility / QtLocation in Qt 5.2

[John Layt]

[Apologies for cross-posting, please reply to kde-core-devel]

Hi,

At QtCS Torsten and I attended the QtLocation session to discuss the
future of the module.  QtLocation was originally part of QtMobility
for Qt4 and was planned to be part of QtEssentials in Qt5, but it was
dropped from Qt5.0 due to being incomplete and un-maintaned, mostly
because the Brisbane development team didn't survive the Digia sale.
Now Digia has re-hired Alex Blasche and he is reviewing all the old
QtMobility modules to see what is worth saving and what should be
dropped entirely, in particular looking to remove all the Nokia cruft
that doesn't belong in a cross-platform toolkit. For example, QtNFC
and QtBluetooth are planned to be revived for Qt5.2 while QtPim is
almost certain to be entirely dropped except maybe for the QtVersit
VCard library.  If there are any QtMobility modules you are interested
in influencing, now is the time to get involved, just email Alex.

QtLocation is seen as high priority and is planned to be revived for
Qt5.2, but in a slimmed-down version.  QtLocation's biggest problem is
that it depends on Qt3D for drawing maps which is currently not
released and is about to undergo a major refactor.  It was also too
monolithic in the past so too heavy a dependency for KDE to depend
upon.  The use of Nokia maps was also an issue for us.  The mapping
C++ api was also incomplete, only QML was really usable.

Alex has made the very sensible decision that shipping QtLocation in
its current form any time soon is impossible, but that the positioning
functions (i.e. "Where am I?") are vital to have and what most apps
are really interested in, so will be breaking out the positioning api
into a separate module QtPosition(?) for Qt 5.2.  On Linux this module
will support the use of GeoClue or Gypsy as a runtime dependency.  The
exact break line is still not clear but is open to influence, i.e will
geo-coding be part of this or not?

The general opinion on the mapping module is that the current design
is overkill for most apps who just need to show where the user is
located and don't need whizzy 3D views or routing information, etc.
Ideally the existing mapping solution would be almost completely
re-written without the advanced features and dependence on Qt3D, but
with only 1 person currently working on all of QtMobility it may not
be practical to do either option so may never be released.

I asked Alex about moving the fundamental data types like QGeoLocation
into QtCore to allow them to be used in the likes of Nepomuk and
Akonadi without depending on QtPosition, he wasn't convinced but
agreed to think about it so I will keep pursuing it.  Worst case is
they will stay in QtPosition but that should be a very light
dependency if really needed.

This result is a Very Good Thing(TM) for KDE. It will give us a
simple, light-weight positioning api to use as part of our core api
(and possibly in libmarble as the positioning backend), may bring a
light-weight slippy map api for very basic map display, and reinforce
the position of libmarble as the premier Qt mapping solution.

Alex is looking for help with the work, and having a KDE person
influencing the feature decisions made would be a good thing,
especially with removing the Nokia cruft and moving to a more open
standards compliant model, so if there's someone out there who knows
their stuff and has the time please jump on in :-)

Cheers!

John.