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 <[email protected]>: > Hi > > On 09/14/2016 12:01 PM, Luigi Pirelli wrote: >> On 14 September 2016 at 11:20, Matthias Kuhn <[email protected]> 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 > [email protected] > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
