Re: [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing

On 05/02/18 17:06, Rashad Kanavath wrote:
> 
> 
> On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert 
> <[email protected] <mailto:[email protected]>> wrote:
> 
>     On 05/02/18 13:51, Helmut Kudrnovsky wrote:
> 
>         Von: "Moritz Lennert"
> 
>             I don't know how difficult it would be to create such algorithm
>             descriptions automagically.
> 
>         https://github.com/qgis/QGIS/search?p=1&q=processing+grass&type=&utf8=%E2%9C%93
>         <https://github.com/qgis/QGIS/search?p=1&q=processing+grass&type=&utf8=%E2%9C%93>
> 
>         AFAIU there are some general python scripts to provide it in
>         processing:
> 
>         e.g.
>         python/plugins/processing/algs/grass7/Grass7AlgorithmProvider.py
> 
> 
>     No, this is the provider itself, not a tool to create the descriptions.
> 
> 
>         and there are a lot of txt files providing the module interface
> 
>         e.g
>         python/plugins/processing/algs/grass7/description/r.out.png.txt
>         r.out.png
>         Export a GRASS raster map as a non-georeferenced PNG image
>         Raster (r.*)
>         QgsProcessingParameterRasterLayer|input|Input raster|None|False
>         QgsProcessingParameterNumber|compression|Compression level of
>         PNG file (0 = none, 1 = fastest, 9 =
>         best)|QgsProcessingParameterNumber.Integer|6|True|0|9
> 
>         and other files
> 
> 
>     My question was whether it would be possible to create these
>     description files more or less automagically.
> 
>     I think the python scripts for more complex operations have to be
>     created manually.
> 
>     IIUC (from rapid reading of the threads on the qgis-developer list),
>     Rashad's suggestion was to keep the *AlgorithmProvider code in the
>     QGIS code base, but to possibly move the creation of the description
>     and script files to a plugin managed outside QGIS core, possibly by
>     the respective external software teams.
> 
> 
> Yes. your are right on track! the idea is external tools (processing 
> providers) manage descriptor files in a format requested by qgis 
> processing.
> I see already name-of-grass-module --interface-descriptor which gives an 
> xml for GRASS gui.
> what qgis want is a csv in a specific format. The contents of qgis 
> descriptor seems much less compared to --interface-descriptor.
> Correct me if I am wrong, --interface-descriptor is available in all 
> grass modules. So maybe a --qgis can do the work.

Yes, this is what I was aiming at.

> 
> This has some advantages.
> * GRASS developers are free to fix parameter name, parameter 
> description, list of modules(add and remove) changes without affecting qgis.
> * grass 7.5 has 10 modules and grass 7.9 can have 15 and same QGIS will 
> work.
> * QGIS will not need to maintain these files and keep updating/adding 
> new modules with their release process. whatever is generated from a 
> grass build/install have better integration with qgis
> * Finally this descriptors for qgis are generated with a makefile target 
> that allows users and packagers to include it.
> * QGIS can use multiple version of grass by changing install prefix 
> because descriptors are *always* found in a directory relative to 
> install prefix.
> 
> QGIS provider will be like:
> I picked a descriptor file
> parse and make the ui,
> take input and execute whatever program the descriptor is to run.
> 
> QGIS already manages parsing of parameters and running them. So for 
> providers who wish to be integrated in qgis will deal with a descriptor 
> file and things go fine.
> 
> Having a single interface to launch all or most of toolboxes (willing to 
> contribute descriptor with installation) can have same way of execution. 
> At that point, QGIS should consider
> adding some generic code in provider and avoid plugins for such toolboxes.

Thanks for the explanation / confirmation, Rashad.

Now, the question is whether this is in line with the ideas of the QGIS 
developers...

Moritz
_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev