Right, I see you your point. I havent been able to follow the recent developments in Processing, and i have to admit i am a little bit lost (Nyall has been working too fast!!). So this is just my opinion, but it might not make sense in the current situation.
I will try to get up to date as soon as possible :-) Thanks for your collaboration! 2018-01-31 9:24 GMT+01:00 G. Allegri <gioha...@gmail.com>: > I understand your point Victor, and I agree that scripts was a clever idea. > But: > > - with the current shape of Processing (QGIS 3.0) I think the "syntactic > sugar" provided by scripts has less relevance. As I can see from the > refactoring, there's less automation in parameters conversions and > management, and a few new "magic" context variables have been introduced. I > think scripts now are too similar to plain geoalgorithms, and consequently > the differences can become misleading and not easily understood. > > - syntactic sugar requires maintanance: if a new parameter is introduced, i > parameters are added or changed, the corresponding translation method for > scripts must be updated. > > - syntactic sugar requires doc maintanance, while Processing APIs > documentation can be mostly automated. > > Anyway, this is a proposal to be discussed. Meanwhile I will try to estimate > the work needed to drop (and adapt) the current implementations. > > PS: @Victor, it's nice to follow Processing's history! C++ (SAGA) -> Java > (Sextante) -> Python (Processing) -> C++ (QGIS 3.0) :D > > All the best, > Giovanni > > > > 2018-01-31 8:33 GMT+01:00 Victor Olaya <vola...@gmail.com>: >> >> I like the idea, but i dont think it will mean less code, specially >> for defining the parameters and outputs. Why not keeping it for those >> that want to use it this way? >> >> Before removing this (in case it's decided to do so), two things to >> notice: >> >> -- There were algorithms (built-in ones) defined this way, so they >> should be rewritten >> -- There is a little-known functionality that creates a new plugin >> from a set of scripts. It should be adapted as well, or removed. >> >> Thanks! >> >> >> 2018-01-30 21:41 GMT+01:00 G. Allegri <gioha...@gmail.com>: >> > I know there are much more important priorities in view of the QGIS 3.0 >> > release. >> > I will try to implement the idea of Geoalgorithms served by the script >> > provider and, in case, I'll commit a PR for testing and comments. >> > >> > Giovanni >> > >> > Il 29 gen 2018 16:44, "Anita Graser" <anitagra...@gmx.at> ha scritto: >> >> >> >> >> >> >> >> On Mon, Jan 29, 2018 at 2:24 PM, G. Allegri <gioha...@gmail.com> wrote: >> >>> >> >>> What's your opinion >> >>> ? >> >>> >> >> >> >> + >> >> 1 for me, as stated in the original thread >> >> >> >> https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051511.html >> >> >> >> >> >> I think it will be good to unify the approaches. >> >> >> >> Regards, >> >> >> >> Anita >> >> >> >> >> >> >> >> >> > >> > _______________________________________________ >> > QGIS-Developer mailing list >> > QGIS-Developer@lists.osgeo.org >> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > > _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer