[Qgis-developer] Processing C++ algorithms

[Victor Olaya]

Not sure if it's the same...but Alex Bruy and me are thinking about
wrapping core C++ plugins with Processing (mainly the heatmap/terrain
analysis/interpolation plugins). So if you have something new in the
form of a C++, you can also wrap it with Processing

Or what you mean is that you require Processing base classes to be
core adn c++? That could be interesting, and it shouldn't be hard for
the main non-GUI classes...but not sure how it would come up



2016-09-14 12:48 GMT+02:00 Matthias Kuhn <matthias at opengis.ch>:
> Hi
>
> On 09/14/2016 12:01 PM, Luigi Pirelli wrote:
>> On 14 September 2016 at 11:20, Matthias Kuhn <matthias at opengis.ch> wrote:
>>> Hi,
>>>
>>> If one wants to create a C++ processing algorithm, is there any
>>> preferred way to ship it? I don't think we are doing that yet apart from
>>> calling 3rd party tools.
>>>
>>> The possible approaches I can see are
>>>
>>>  * Add a new QGIS module "algs" next to gui/core etc and use
>>>    it's python bindings to call the code from a small python wrapper.
>>
>> overhead?
>
> While I am convinced that it is negligible in this case here, if it
> would mater it would be in favor of a C++ implementation because of
> fewer context switches between python/C++. So not for this but for other
> algorithms, such a change could theoretically make a real performance
> benefit.
>
>>
>>>
>>>  * Port some processing core classes to C++, mainly GeoAlgorithm,
>>>    outputs and parameters (and possibly some dependencies).
>>
>> I would be against this... I would leave Processing as pure python
>> core plugin allowing it more dynamic respect qgis release
>
> I think we are no longer shipping band-aid releases through the plugin
> manager.
> Just to make it clear: algorithms can still be implemented in python, I
> don't mean to make any change on this front!!
>
>>
>>>  * Ship it as a separate module and do it all the grass/saga etc. way.
>>
>> IMHO the best solution... what is your use case to justify a different workflow?
>
> Integration with the QGIS ecosystem. A 3rd party binary will not have
> the same level of access to QGIS core functionality, it will need to be
> maintained separately (e.g. API changes), pushed to all the distribution
> repositories. In short: too much overhead and I can mostly discover
> down- instead of upsides.
>
> Matthias
>
>>
>>> Context is, I will probably need this on QField with no python. I could
>>> do it without processing there but since the trend is to processize
>>> whatever possible, I thought it would be a good opportunity to bring
>>> this subject to the table.
>>>
>>> Matthias
>>
>> cheers
>>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer