[GRASS-dev] [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing
mlennert at club.worldonline.be
Mon Feb 5 08:30:09 PST 2018
On 05/02/18 17:06, Rashad Kanavath wrote:
> On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert
> <mlennert at club.worldonline.be <mailto:mlennert at 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.
> AFAIU there are some general python scripts to provide it in
> 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
> 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 =
> 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
> 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
> * 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
More information about the grass-dev