On 14 Sep 2016 9:10 PM, "Victor Olaya" <[email protected]> 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 <[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
_______________________________________________ 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
