On 31 January 2018 at 18:24, G. Allegri <gioha...@gmail.com> wrote: > 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
I'm a bit late to this discussion, but my 2c: - I actually like the idea of single file script algorithms, and don't want to see them go. I can see lots of valid use cases for why they are needed. (In particular - I'd love to extend models in future to allow embedded script algorithms which are contained just within a single model, and not exposed elsewhere). - It's just the syntax of scripts which I'm not a fan of (for reasons well covered above) Alex has a WIP PR already at https://github.com/qgis/QGIS/pull/6225 - stakeholder comments would be welcome here! Nyall _______________________________________________ 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