[Qgis-developer] Processing C++ algorithms

[Nyall Dawson]

On 14 Sep 2016 9:10 PM, "Victor Olaya" <volayaf at gmail.com> wrote:
>
> 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

I personally would advise against wrapping the heat map plugin in its
current form. It needs some major reworkings and much better separation of
ui/algorithm.

But I'd very much like to see the guts of this moved to core or analysis
(or potentially "alg"!) and it made reusable for plugins and processing.

Nyall

>
> 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
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20160914/af3663b5/attachment.html>