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