[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. _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
