[QGIS-Developer] Add cpp plugin API for 3D view

[Benoit D.-M.]

Hi,

Currently, apart from the `./plugins/qgisplugin.h` file, there is no 
formal contract for the other C++ plugin APIs; if the C++ API changes, 
external plugins might break. We are aware of the API's instability and 
accept the risk that it may change in the future.

Furthermore, converting this API to Python is far from straightforward, 
as the Qt3D objects involved cannot be exposed to Python.

Have you any other concerns?

Benoit.

Le 05/09/2026 à 01:17, Nyall Dawson a écrit :
> On Sat, 5 Sept 2026 at 00:29, Benoit D.-M. via QGIS-Developer
> <qgis-developer at lists.osgeo.org> wrote:
>> Hello everyone,
>>
>> as you maybe know, we (Oslandia) are working on several 3D functionalities for our customers, that we aim to add to QGIS core. Among them are 3D editing capabilities.
>>
>> Nevertheless, the specific QEP discussion [1] about editing, points toward a broad technical redesign that is out of scope for our current project, this is why we propose to ship the features within a QGIS C++ plugin to gather users feedback and contribute to the discussion on the 3D UI.
>>
>> In order to achieve this we propose adding accessors to the 3D view that enable the creation of an external QGIS plugin in C++, incorporating the relevant features. These new API accessors will be considered unstable API and not exposed in Python.
>> The changes are developed in the following PR:https://github.com/qgis/QGIS/pull/67298
>>
>> Do you see any drawbacks to these changes?
>>
> I'm not a -1, but my concern would be that we don't have any formal
> policies for non-Python API. It's easy right now to determine if
> you've broken the rules by just checking the changes to the sip
> bindings and evaluating if they'd have broken any Python scripts. If
> we introduce API that's solely for c++ plugins, how we will handle the
> stable API? I can definitely see someone seeing all the unused lines
> of code in future and (rightly!) killing them all. And if you scatter
> "please do not remove" comments throughout the code, those will remain
> forever and become a permanent road block to development, even if the
> c++ plugin is dead or no longer uses that API.
>
> My gut feeling is that you should do this via the existing way, by
> developing APIs that are sufficiently well designed to be eligible to
> become part of the (python) GUI stable API. If you're dead-set on the
> c++ plugin API approach, then a QEP formalising some policies for this
> is needed first.
>
> Nyall
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260909/92ed69f3/attachment.htm>