[QGIS-Developer] QGIS-Developer Digest, Vol 251, Issue 26

Wed Sep 30 05:01:03 PDT 2026

Hi All

On 2026/09/30 13:32, qgis-developer-request at lists.osgeo.org wrote:
> Send QGIS-Developer mailing list submissions to
> 	qgis-developer at lists.osgeo.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://lists.osgeo.org/mailman/listinfo/qgis-developer
> or, via email, send a message with subject or body 'help' to
> 	qgis-developer-request at lists.osgeo.org
>
> You can reach the person managing the list at
> 	qgis-developer-owner at lists.osgeo.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of QGIS-Developer digest..."
>
>
> Today's Topics:
>
>     1. Re: Add cpp plugin API for 3D view (Benoit D.-M.)
>     2. Are there any real mandatory rules for publishing a plugin?
>        (Stefano Campus)
>     3. Subject: Proposal: Direct MBTiles-to-TPKX Conversion for QGIS
>        (Jim)
>     4. Re: Are there any real mandatory rules for publishing a
>        plugin? (Nicolas Godet)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 29 Sep 2026 16:40:01 +0200
> From: "Benoit D.-M."<benoit.de.mezzo at oslandia.com>
> To: qgis-developer<qgis-developer at lists.osgeo.org>
> Subject: Re: [QGIS-Developer] Add cpp plugin API for 3D view
> Message-ID:<5536fc00-7fff-4872-b3c4-a2519dae8bd9 at oslandia.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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-0001.htm>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 29 Sep 2026 17:44:48 +0200
> From: Stefano Campus<skampus at gmail.com>
> To: qgis-dev<qgis-developer at lists.osgeo.org>
> Subject: [QGIS-Developer] Are there any real mandatory rules for
> 	publishing a plugin?
> Message-ID:
> 	<CAHw6TZdp06hS2QG3QNB1jGHUKo72J79C9z_nvYfNHP6Kv0oXgg at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Good morning,
> a few days ago, a plugin [1] was released that is a fork of an existing
> plugin which had been updated (without the original plugin author being
> notified) to QGIS 4.
> The GitHub repository has issues disabled, so it is not possible to report
> bugs that are present.
>
> But shouldn?t it be mandatory to have issue reporting enabled?
>
> Furthermore, the proliferation of plugins makes it difficult to find the
> truly innovative ones.
> So we see plugins that replicate core functions, perhaps giving them a more
> appealing user interface
>
> Where can I report this to the team that coordinates the plugins?
> Do you think we should report these anomalies?

The plugin ecosystem has become a jungle. Last year at this time i used 
to review/approve a maximum of 10 plugins a day but these days, i look 
at more than 20 plugins a day which approximately equates to 30-45 
minutes of my time.

As we currently sit, we are looking at

ap

plugins that need to be reviewed between Tuesday and today.

There are no hard rules in terms of what each plugin should offer in 
terms of functionality. For plugins that have the same functionality, we 
always encourage the authors to merge their work but we also saw a lot 
of resistance from some developers who did not accept a fellow 
developer's pull request for days and in some cases months. So we ended 
up in situations where we had to accept the plugin thereby having 2 
similar plugins because we cannot force a developer of plugin X to 
incoperate changes that are coming from developer Y because the original 
author thinks his plugin will diverge from it's original focus.

In terms of plugins replicating core functionality, we also alert 
developers to this and in most cases they always have a ready made 
explanation of what the plugin does different to the core functions. 
Because the developer has spend some considerable time to develop this 
and maybe it benefits his core focus group, how then can we block 
his/her plugin from being published.

If there is a plugin that has issue reporting banned please contact me 
and I will investigate. It might just have been oversight from the 
burnout in managing plugins.

Lastly the definition of a plugin may need to be fleshed out better 
because the majority of plugins I review could in effect be scripts that 
are used locally by the specific individual or team.

Regards

Admire

>
> Many thanks
>
> stefano
>
> [1]https://github.com/veogeo/go3streetview
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:<http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260929/2fa84a17/attachment-0001.htm>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 29 Sep 2026 20:24:07 +0000 (UTC)
> From: Jim<dc95811 at yahoo.com>
> To:"qgis-developer at lists.osgeo.org" <qgis-developer at lists.osgeo.org>
> Subject: [QGIS-Developer] Subject: Proposal: Direct MBTiles-to-TPKX
> 	Conversion for QGIS
> Message-ID:<1507850343.1295031.1790713447194 at mail.yahoo.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hello QGIS Development Team,
> My name is Jim Gaddy. I'm an independent technical experimenter who has been working on making offline map production accessible to people without formal GIS training.
> Working with ChatGPT, I've developed and field-tested a small, open-source Python converter that transforms standard raster MBTiles directly into native Esri Compact Cache V2 TPKX files.
> The converter preserves the original imagery and individual zoom levels without intermediate GeoTIFF conversion or ArcGIS Pro. I've successfully used its output in ArcGIS Earth, including large metropolitan imagery datasets.
> The complete program, technical documentation and MIT License are publicly available here:https://github.com/Jim-dc95811/QGIS-Mbtile-to-ArcGIS-Earth-TPKX
> I've also published a short tutorial demonstrating the complete QGIS-to-ArcGIS Earthworkflow:https://www.youtube.com/watch?v=C71n8TAByuE
> I'd like to explore contributing this functionality to the QGIS community, ideally as an operation accessible through the Processing Toolbox.
> Would you recommend developing it as an independent Processing plugin, or proposing its integration into QGIS itself?
> I welcome your technical feedback and would appreciate guidance on the appropriate contribution process.
> Thank you for your time.
> Jim Gaddy
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:<http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260929/9d51c906/attachment-0001.htm>
>
> ------------------------------
>
> Message: 4
> Date: Wed, 30 Sep 2026 11:31:59 +0000
> From: Nicolas Godet<nicolas.godet at outlook.fr>
> To: Stefano Campus via QGIS-Developer<qgis-developer at lists.osgeo.org>
> Cc: qgis-dev<qgis-developer at lists.osgeo.org>
> Subject: Re: [QGIS-Developer] Are there any real mandatory rules for
> 	publishing a plugin?
> Message-ID:
> 	<MRWPR05MB1240646A5F3A44AC63A3A6B568F8B2 at MRWPR05MB12406.eurprd05.prod.outlook.com>
> 	
> Content-Type: text/plain; charset="utf-8"
>
> Dear all,
>
> I can?t agree more on the fact that the plugin repo has become a wild jungle with less and less interest in digging into it to find an innovative one.
> A few years ago, I spent a few minutes each week looking at each new plugin (because there were only ten or so). Now, I don?t look at new plugins anymore because there are too many of them and most of them are a duplicate of another plugin or, even worse, of a core feature.
>
> I think new rules should be put in place or at least a way to distinguish good, community-approved plugins from the nonsense garbage in the quest for likes for their LinkedIn post.
>
> Kind regards,
> Nicolas
>
> Le 29 sept. 2026 ? 17:45, Stefano Campus via QGIS-Developer<qgis-developer at lists.osgeo.org> a ?crit :
>
> ?
> Good morning,
> a few days ago, a plugin [1] was released that is a fork of an existing plugin which had been updated (without the original plugin author being notified) to QGIS 4.
> The GitHub repository has issues disabled, so it is not possible to report bugs that are present.
>
> But shouldn?t it be mandatory to have issue reporting enabled?
>
> Furthermore, the proliferation of plugins makes it difficult to find the truly innovative ones.
> So we see plugins that replicate core functions, perhaps giving them a more appealing user interface
>
> Where can I report this to the team that coordinates the plugins?
> Do you think we should report these anomalies?
>
> Many thanks
>
> stefano
>
> [1]https://github.com/veogeo/go3streetview
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:<http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260930/e90ec076/attachment.htm>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info:https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ------------------------------
>
> End of QGIS-Developer Digest, Vol 251, Issue 26
> ***********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260930/bea17bfd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2026-09-30 at 13.58.33.png
Type: image/png
Size: 103805 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20260930/bea17bfd/attachment-0001.png>