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

[Benoit D.-M.]

Hello,
I have updated the PR. To summarize, we want to introduce two APIs:
- the ability to define editing toolbars (the point cloud editing 
toolbar has been updated to use this API)
- the ability to dynamically add widgets to the sidebar.

What do you think?

Benoit.

Le 09/09/2026 à 09:34, Benoit D.-M. via QGIS-Developer a écrit :
>
> 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/20260929/02f6438f/attachment.htm>