Hi, In general I would say that both sides (QGIS – GRASS) benefit from an integration like Processing or the GRASS plugin. QGIS gains algorithms, GRASS gains user base. And for the future, Rashads and Moritz proposal make indeed a lot of sense!
The text descriptor files have been a real pain for maintaining interfaces for GRASS integration in Processing as well as the GRASS plugin. In addition, they make usage of AddOns practically impossible for most of the QGIS users. However, for QGIS (and this is true for both integrations), the module UI was deliberately simplified by hiding / removing “advanced” option or splitting modules into “sub-types”. In addition not all modules could be meaningful added to the two QGIS integrations (e.g. temporal modules in Processing). And finally, some require extra work on the QGIS side (like r.mapcalc). So, I would assume that a --qgis-descriptor solution would be most appropriate. But that would still require additional work (beyond implementing a parser solution) if the principles for the GRASS module UI in QGIS should stay as it is, like: - Tagging options and flags as advanced or basic/main/common (could be an opportunity to consolidate terminology in the module UI in GRASS as well) - Deciding which modules to use / exclude from QGIS (and how to mark them) - … Maybe also Ondrejs work could be useful here : https://trac.osgeo.org/grass/wiki/GSoC/2016/PyQtGUI ? Cheers Stefan From: grass-dev [mailto:grass-dev-boun...@lists.osgeo.org] On Behalf Of Rashad Kanavath Sent: mandag 5. februar 2018 17.06 To: Moritz Lennert <mlenn...@club.worldonline.be> Cc: grass-user@lists.osgeo.org; grass-...@lists.osgeo.org; Helmut Kudrnovsky <hel...@web.de> Subject: Re: [GRASS-dev] [GRASS-user] Keeping GRASS/OTB/... algorithm in qgis processing 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 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. 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. Moritz _______________________________________________ grass-dev mailing list grass-...@lists.osgeo.org<mailto:grass-...@lists.osgeo.org> https://lists.osgeo.org/mailman/listinfo/grass-dev -- Regards, Rashad
_______________________________________________ grass-user mailing list grass-user@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-user
