QtLocation implementing new back-end

  • Hi all,
    I've some questions regarding implementing new back-end for qtlocation/places purposes.
    There is something about how to start in Qt's documentation starting from:
    in section:
    Implementing New Back-Ends and Porting

    And nowhere on those sites I can find any info how to approach adding support for displaying maps. I don't mean how to display map using C++ API. It is clearly said somewhere in Qt's docs that there is no support for that, but when I'm implementing new QtLocation plugin if I'll add support i.e. for working with places (overrided method createPlaceManagerEngine inside my QGeoServiceProviderFactory) I also should add support for displaying map (by overriding createMappingManagerEngine inside my QGeoServiceProviderFactory? -there is question mark cause QGeoServiceProviderFactory has virtual method createMappingManagerEngine but official Qt's docs are not saying a word about it). But here is the root cause of my confusion - all stuff related to displaying maps QGeoMappingManagerEngine or QGeoTiledMappingManagerEngine and many other are private API's, there are even warning about this fact inside headers.
    Which means if anybody want to implement own QtLocation plugin needs to extend private API which can be radically changed or removed within next release.
    Can anybody explain me if I'm missing something or if not what is the purpose for hiding MappingManagerEngine's implementation/API into private headers?

    Thanks in advance.

  • Lifetime Qt Champion


    Do you mean you would like to implement something similar to the Google Maps plugin ?

  • Yes, that's good example.
    Currently all I need is to extend OSM plugin to support alternative sources while searching places, but I wasn't interested in extending official plugin cause I'm not sure if such a feature would be interesting for community, so I started to studying plugins sources and found that MappingManager's sources are private implementation hidden inside QtLocation module. Which brings me questions like those I've already asked.
    I said Google Maps plugin implementation is good example but not exactly. Such a code can be provided for community and if will be merged to official Qt's sources there is no problem if something became internal implementation as long as it works. What about if somebody works on some mapping data which are not accessible for free like Google Maps, OSM etc. ? Only commercial or proprietary usage and the plugin's code will not be provided for public usage.
    It would be good to be able to create plugin's implementation without dealing with framework's internal stuff but currently I cannot see such a possibility.

  • Lifetime Qt Champion

    The alternative search source sounds interesting, you should maybe bring this to the interest mailing list. You'll find there QtLocation developers/maintainers. This forum is more user oriented.

    The fact that a data source is not free as in free beer doesn't mean it doesn't belong to the open source licensed Qt. Take for example the Mapbox plugin. They have several level of prices.

  • I'll look into this mailing list, thanks for link.

    Getting back to plugin implementation. Let's say you are working on some app which will provide some indor mapping features. It can be i.e. monitoring of fabric production system, one specific fabric, so nobody else would use their map (of the building). I see QtLocation's features very useful in such a use cases but since there is a need to deal with Qt's internal implementation I'm not sure if it is worth.

  • Lifetime Qt Champion

    While the warning must be taken seriously and changes happen from time to time, they don't happen between every Qt releases.

    I think it's still worth. If the code is to be kept closed source, you would essentially have to run tests when a new release of Qt is delivered to ensure your plugin is still working.

    If you want/need to provide long term support then you can go on with Qt's own LTS which is currently 5.6.

Log in to reply