On 05/02/18 17:06, Rashad Kanavath wrote:
On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert
<mlenn...@club.worldonline.be <mailto:mlenn...@club.worldonline.be>> 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
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
