MapLibre Qt bindings consolidation tracking

[ntadej]

This ticket is meant to track MapLibre Qt bindings consolidation effort and get it ready for the future.

Structure

• Multiple libraries:
  • QMapLibre: main core functionality (without the GL suffix as Metal support is anticipated)
  • QMapLibreGL: outsource dependency on QtOpenGL, for backwards compatibility, to be confirmed if needed
  • QMapLibreLocation: QtDeclarative and QtLocation bindings (name not final yet)
• Plugins:
  • QtLocation plugin
  • QML plugin (to add features on top of QtLocation)

Build system

• CMake 3.21 for Qt 6, CMake 3.19 for Qt 5
• Support Qt5 as long as possible with feature parity.

Licensing

It gets complicated here. Code from Qt is (L)GPL, code from MapLibre is BSD-2-clause.

Progress

• [x] QMapLibre and QMapLibreGL
  • [ ] Figure out how to make QtOpenGL optional
• [x] QMapLibreLocation
  • [x] QtLocation plugin
  • [x] QML plugin
• [x] Examples
  • [x] Widgets app
  • [x] QML app

Tagging @kiibimees, @rinigus and @dpaulat for feedback. I can also add you to the repository if you are interested to contribute.

[rinigus]

Thank you for working on it!

Sorry, I haven't been following the recent developments. In this picture, would Qt support disappear in maplibre-gl-native? If yes, is it planned to outsource all the platforms in such manner?

With the expected split between QMaplibre, QMaplibreGL, QMapLibreLocation, where would a custom QML plugin be able to fit? Right now I have access via QMapLibreGL/Map and QMapLibreGL/Settings API. Is such API planned to be kept?

[ntadej]

The recent changes in maplibre-gl-native motivate spliting individual bindings/SDKs into separate repositories. For example the main branch there now does not work on macOS due to OpenGL update (until Metal support is done). The idea is to decouple the core from client-facing code so that they can be developed independently. Qt will act as a proof of concept, but it will also help me properly support final Qt6 QtLocation API.

QMapLibre and QMapLibreGL would be the same for now. Maybe we can drop GL from the name also later, but maybe now is a good opportunity with reorganisation (hopefully final one for a while!). Eventually when Metal is done (and later maybe Vulkan), users may not want to depend on QtOpenGL library.

The idea is that QMapLibre(GL) contains what it does now - core Map class that has minimal dependencies on Qt modules. Besides a potential rename, nothing will change to you (when metal is ready, some API will probably change). QML and QtLocation stuff goes in a separate library so only people that want to use it, use it.

[rinigus]

Sounds great! The QML plugin that you mention with QMapLibreLocation is the one that will plugin into Qt6 QtLocation, right?

Thank you very much for explaining!

[ntadej]

Yes, that's correct. I want to put it in a separate library so we can make our custom public API, but still have it separated from core if people (like you) do not want to use QtLocation.

[dpaulat]

From a technical standpoint, all of the above sounds just fine for my use case. If I can continue to use MapLibre within a QOpenGLWidget, I'm happy.

My main concern about your original statement is licensing. My preference would be that the MapLibre components would retain their BSD licensing. I wouldn't want to be exposed to additional LGPL requirements (I would begrudgingly accept), and GPL is a non-starter for me (I believe the Qt modules in question are LGPL).

[ntadej]

Indeed I plan to keep QMapLibreGL licensed under BSD to help Qt commercial users.

For open-source users they are anyways directly bound by LGPL due to Qt itself.

[rinigus]

I want to put it in a separate library so we can make our custom public API, but still have it separated from core if people (like you) do not want to use QtLocation.

I wonder what would that "custom public API" would be. Is that something different from the one used by Qt in QtLocation QML?

[ntadej]

I wonder what would that "custom public API" would be. Is that something different from the one used by Qt in QtLocation QML?

The end result will probably be very similar to DynamicParameter in Qt5 which was now removed (Mapbox/MapLibre was the only client). I may add a bit more type safety.

[ntadej]

Tagging also @kiibimees

[ntadej]

I wonder if any of you would be willing to help with review here? A general policy is that we do not merge stuff without one review so help may speed-up the development + you may spot issues that relate to you.

[rinigus]

I think we have to :) . I'll try to review as much as I can.

[ntadej]

OK, I'll add you as a member to this repository. Thank you in advance for your help!

[kiibimees]

To revew what exactly? :)

[ntadej]

The idea was to give you access to the repo and you can sign-off PRs.

[kebekus]

@ntadej I would like to report an issue with the current (=15Feb24) Qt bindings. Is this the right place for it? Please let me know if it isn't.

I use MapLibre with QML. The map contains a source parameter of the following form.

        SourceParameter {
            id: approachChart

            styleId: "vac"
            type: "image"

            property string url: functionA()

            property var coordinates: functionB()

        }

I observe the following behavior:

• The QML binding for the property "url" works beautifully. The map updates the image whenever the property "url" changes.

• The QML binding for the property coordinates does not work at all. When the property "coordinates" changes, nothing happens at all. Currently, the only way to move the image on the map is to discard the map and construct a new one. This is time-consuming and leads to visible glitches in the display.

Would it be possible to update the code so that changes in the "coordinates" property are reflected in the map?

@ntadej Let me thank you again for maintaining this marvelous piece of software!

Best,

Stefan.

[ntadej]

Hi @kebekus, can you please open a separate issue for this?

[kebekus]

Hi @kebekus, can you please open a separate issue for this?

Done.