Parameter metadata: add the capability to use parameter description

[rldhont]

The default inputs to R script are based on the QGIS parameter asScriptCode / fromScriptCode string definition.

QGIS also provide an other way to describe processing parameters used in GRASS7, SAGA and other processing providers. We propose to reuse this capability. The metadata line looks like QgsProcessingParameter|name|description|other_parameters_separated_by_pipe.

The inputs can look like this:

##QgsProcessingParameterFeatureSource|INPUT|Vector layer specifies that there will be variable INPUT that will be a vector.

##QgsProcessingParameterField|FIELDS|Attributes|None|INPUT|-1|False|False specifies that there will be variable FIELDS that will be a field index.

##QgsProcessingParameterRasterLayer|INPUT|Grid specifies that there will be variable INPUT that will be a raster.

##QgsProcessingParameterNumber|SIZE|Aggregation Size|QgsProcessingParameterNumber.Integer|10 specifies that there will be variable Size that will be numeric, and a default value for Size will be 10.

##QgsProcessingParameterEnum|METHOD|Method|[0] Sum;[1] Min;[2] Max specifies that there will be variable METHOD that will be a value provided under [].

##QgsProcessingParameterVectorDestination|OUTPUT|Result specifies that there will be variable OUTPUT that will be the destination vector layer.

[JanCaha]

This seems like a really nice addition. Looking at the code, it is well done, tests are passing and it is backwards compatabile. So 👍 from me.

@nyalldawson is this conceptually ok? It adds another layer of complexity into script definition, but definitely offers something that experience users (myself included) want. I am happy to handle the pull request and everything just wanted your say-so on this.

[nyalldawson]

@JanCaha

is this conceptually ok?

I think so. A quick summary of my thoughts:

• I think the R provider is the only user of the simplified "##some_layer=vector" approach, so by moving to the same method as is used by the inbuilt grass/saga/otb providers we gain an extra level of safety and upstream attention, that's a good thing
• The new method supports a lot more of the extra settings and option for parameters, which will give more flexibility in scripts
• The one downside is that the newer format is more complex for users, and exposes them to the internals of QGIS processing via the use of the Qgs...* class names for parameters and the need to follow the QGIS class constructor arguments when defining parameters. That's a bit of a step backwards for new users vs the simplified existing approach. For that reason I'd prefer we support both methods for the foreseeable future, and "brand" the newer format as "advanced" in the documentation...

[JanCaha]

Ok, that is pretty much what I have in mind.

@rldhont or @Gustry could you please edit the web page in such way this new approach is summarized under # Advanced Script syntax in script-syntax.md? So that we have the descriptions for original approach and then this new one?

Then I think we can bump the version to 3.0.0, do some testing and ask Nyall to make a new release.

[rldhont]

@JanCaha done.