<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 5, 2018 at 2:49 PM, Moritz Lennert <span dir="ltr"><<a href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 05/02/18 13:51, Helmut Kudrnovsky wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Von: "Moritz Lennert"<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I don't know how difficult it would be to create such algorithm<br>
descriptions automagically.<br>
</blockquote>
    <a href="https://github.com/qgis/QGIS/search?p=1&q=processing+grass&type=&utf8=%E2%9C%93" rel="noreferrer" target="_blank">https://github.com/qgis/QGIS<wbr>/search?p=1&q=processing+grass<wbr>&type=&utf8=%E2%9C%93</a><br>
<br>
AFAIU there are some general python scripts to provide it in processing:<br>
<br>
e.g.<br>
python/plugins/processing/algs<wbr>/grass7/Grass7AlgorithmProvide<wbr>r.py<br>
</blockquote>
<br></span>
No, this is the provider itself, not a tool to create the descriptions.<span><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
and there are a lot of txt files providing the module interface<br>
<br>
e.g<br>
python/plugins/processing/algs<wbr>/grass7/description/r.out.png.<wbr>txt<br>
r.out.png<br>
Export a GRASS raster map as a non-georeferenced PNG image<br>
Raster (r.*)<br>
QgsProcessingParameterRasterLa<wbr>yer|input|Input raster|None|False<br>
QgsProcessingParameterNumber|c<wbr>ompression|Compression level of PNG file (0 = none, 1 = fastest, 9 = best)|QgsProcessingParameterNu<wbr>mber.Integer|6|True|0|9<br>
<br>
and other files<br>
<br>
</blockquote>
<br></span>
My question was whether it would be possible to create these description files more or less automagically.<br>
<br>
I think the python scripts for more complex operations have to be created manually.<br>
<br>
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.</blockquote><div><br></div><div>Yes. your are right on track! the idea is external tools (processing providers) manage descriptor files in a format requested by qgis processing. </div><div>I see already name-of-grass-module --interface-descriptor which gives an xml for GRASS gui. </div><div>what qgis want is a csv in a specific format. The contents of qgis descriptor seems much less compared to --interface-descriptor.</div><div>Correct me if I am wrong, --interface-descriptor is available in all grass modules. So maybe a --qgis can do the work.</div><div><br></div><div>This has some advantages.</div><div>* GRASS developers are free to fix parameter name, parameter description, list of modules(add and remove) changes without affecting qgis.</div><div>* grass 7.5 has 10 modules and grass 7.9 can have 15 and same QGIS will work.<br></div><div>* 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</div><div>* Finally this descriptors for qgis are generated with a makefile target that allows users and packagers to include it. </div><div>* QGIS can use multiple version of grass by changing install prefix because descriptors are *always* found in a directory relative to install prefix.</div><div><br></div><div>QGIS provider will be like:</div><div>I picked a descriptor file</div><div>parse and make the ui, </div><div>take input and execute whatever program the descriptor is to run.</div><div><br></div><div>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.<br></div><div><br></div><div>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</div><div>adding some generic code in provider and avoid plugins for such toolboxes.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="m_-8535335737944291886HOEnZb"><font color="#888888"><br>
<br>
Moritz</font></span><div class="m_-8535335737944291886HOEnZb"><div class="m_-8535335737944291886h5"><br>
______________________________<wbr>_________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org" target="_blank">grass-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/grass-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailma<wbr>n/listinfo/grass-dev</a></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="m_-8535335737944291886gmail_signature" data-smartmail="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</div></div>