<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 7, 2018 at 3:03 PM, Victor Olaya <span dir="ltr"><<a href="mailto:volayaf@gmail.com" target="_blank">volayaf@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I dont think that it is possible to make it more generic. It's not only descriptors with only outputs and inputs. Each backend app has its own logic. GRASS needs outputs to be converted to its own format. SAGA accepts only SHP for vector layers and generates its own SDAT format for raster outputs. Parameters are also not passed in the same way to all apps. SAGA has extent parameters splitted in 4 params with bbox coordinates. Each provider has a different way of indicating a boolean value in the console call. In short, the logic must be there somehow, specific for the provider,</div></blockquote><div><br></div><div>can you confirm that a GRASS input/output parameter can solve their issue?.</div><div>Still there is SAGA and other stuff. So generic provider is not something QGIS team can do. But I would like to know about this on GRASS issue.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>What is the difference between maintaining a set of descriptor files (as you propose) and a set of descriptor files + a class extending GeoAlgorithmProvider with the logic (as it happens now)?. I think it is easier to have a solid provider class for OTB and then do not ever change it (assuming OTB syntax will never change), than having a generic provider, which looks rather unfeasible.</div><div><br></div></div></blockquote><div>Still OTB requires some changes in processing plugin to work. the old way of twisting application only for QGIS must be avoided. </div><div>Without such a change there is no long-term existence even as plugin. Or worse, it exists and will be broken. </div><div>QGIS must recognize such a behavior and avoid adding  burden on external toolboxes' developer teams by asking for splitting applications. Be it OTB, GRASS, SAGA whatever.<br></div><div><br></div><div>While I was at it, I saw there is less stuff to be managed and can be done using a customwidgetwrapper for OTB. because a custom widget wrapper works in a special way only for one provider.</div><div>Hence the idea of generic provider came up!.  In  case of GRASS its input/output parameter, for OTB it is selection list parameter.</div><div><br></div><div>Thanks for your valuable feedback on this. I am sure an idea of generic provider came up sometime during your work on processing plugin. </div><div>It tough and need more expert work and safe is to avoid it totally. I agree on that part.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div></div><div>As you say, there is the risk for dead code. In that case, i think it is much better to have the provider outside of QGIS core, as a plugin. There are dozens of dead plugins, and that is not nice, but it's kinda acceptable. Having dead code in QGIS it's a much bigger issue, and we must avoid that.</div><div><br></div><div>Cheers</div><div><br></div><div><br></div></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">2018-02-07 14:41 GMT+01:00 Rashad Kanavath <span dir="ltr"><<a href="mailto:mohammedrashadkm@gmail.com" target="_blank">mohammedrashadkm@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hello victor,<div><br></div><div>Do you see a possibility of a generic processing provider?. One that can read descriptor files and run algorithms!.</div><div>I see processing as a single plugin (included in QGIS or not). And if it can avoid need to have sub-plugin managed by all those other development team. That's even better!.</div><div>Whichever toolbox want to be integrated into processing plugin can provide and maintain descriptor files individually. No QGIS developers need to be involved.</div><div>This way, external toolboxes' team or qgis does not need to maintain/fix qgis-<TOOLBOX>-provider-plugin<wbr>.  </div><div><br></div><div>search -> download -> install plugin will be changed to configure providers install location.</div><div>If needed QGIS can control list of available providers (just names). <br></div><div><br></div><div>External tools' dev team needs to know something such as spec of descriptor files, how to mention name of executable etc. <br></div><div>They don't need to know stuff like how qgis run a processing algorithm, and things working of modeler, running with other algorithms.</div><div><br></div><div><div>Anyway, this is just an idea and don't know what will be technically challenging issues?</div></div><div><br></div><div>The other way of putting processing plugin into core and providers classified as external plugins can avoid maintenance on qgis.  </div><div>But this "strategy" can result in dead code and users complaining on both projects. Because, at some developers cannot manage project release + a plugin for qgis, another plugin for matlab or whatever</div><div>Putting all stuff in qgis tree and taking no responsibility of providers isn't good either. </div><div><br></div><div>This way, each team takes part and result in better collaboration and contribution.<br></div><div>As time goes, generic descriptor provider gets better and stronger.  Toolboxes are free to add, remove, modify their applications and users from both community benefit best of both worlds.<br></div><div><br></div></div><div class="gmail_extra"><div><div class="gmail-m_134696852637611417h5"><br><div class="gmail_quote">On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya <span dir="ltr"><<a href="mailto:volayaf@gmail.com" target="_blank">volayaf@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I dont see the advantage in having providers in core. And if there is an advantage, it's clearly not in how easy it is going to be to maintain the plugin. If the people responsible of a given backend (like OTB) are going to maintain it (which makes sense), why putting it in core where they don't have write access? Better in a separate repo. Also, they can release whenever there are changes, without having to wait for a new release. That way, the plugin will always be in sync with new releases of the backend app.<div><br></div><div>If we put them in core...why putting only this big ones (which in some cases require installing external apps manually by the user), and not put other plugins that exist and contain Processing providers? </div><div><br></div><div>I thought the idea was to not have core plugins and avoid them if possible. I don't see why we have to treat plugins that have Processing provider in a different way. Specially considering how easy it is to install a plugin in QGIS.</div><div><br></div><div>Cheers</div><div><br></div><div><br></div></div><div class="gmail-m_134696852637611417m_-8017977145189033129HOEnZb"><div class="gmail-m_134696852637611417m_-8017977145189033129h5"><div class="gmail_extra"><br><div class="gmail_quote">2018-02-06 18:57 GMT+01:00 Paolo Cavallini <span dir="ltr"><<a href="mailto:cavallini@faunalia.it" target="_blank">cavallini@faunalia.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
following the discussion on qgis-dev ML:<br>
<a href="https://lists.osgeo.org/pipermail/qgis-developer/2018-January/051701.html" rel="noreferrer" target="_blank">https://lists.osgeo.org/piperm<wbr>ail/qgis-developer/2018-Januar<wbr>y/051701.html</a><br>
it has been proposed to remove all external providers (namely OTB,<br>
already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will<br>
remain as QGIS cannot be built without). This raised a number of<br>
concerns, so PSC decided not to rush removing them from the upcoming 3.0<br>
release, and to open a wider discussions about this, involving all the<br>
interested parties, to find an optimal solution.<br>
If volunteers outside QGIS core team, ideally from the respective<br>
backends, could take the maintenance of these providers, not much would<br>
change for the end user. If not, this will mean effectively missing<br>
hundreds of algs from QGIS.<br>
I personally propose to reinstate the OTB plugin with Rashad (from OTB)<br>
as maintainer.<br>
<a href="http://QGIS.ORG" rel="noreferrer" target="_blank">QGIS.ORG</a> will seek to support any decision made with funding where possible.<br>
Looking forward for your feedback.<br>
All the best.<br>
<span class="gmail-m_134696852637611417m_-8017977145189033129m_6321785772542877111HOEnZb"><font color="#888888">--<br>
Paolo Cavallini - <a href="http://www.faunalia.eu" rel="noreferrer" target="_blank">www.faunalia.eu</a><br>
QGIS & PostGIS courses: <a href="http://www.faunalia.eu/training.html" rel="noreferrer" target="_blank">http://www.faunalia.eu/trainin<wbr>g.html</a><br>
<a href="https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis" rel="noreferrer" target="_blank">https://www.google.com/trends/<wbr>explore?date=all&geo=IT&q=qgis<wbr>,arcgis</a><br>
</font></span></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="gmail-m_134696852637611417HOEnZb"><font color="#888888">-- <br><div class="gmail-m_134696852637611417m_-8017977145189033129gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div><font face="arial, helvetica, sans-serif">Regards,<br>   Rashad</font></div></div>
</div></div>