On Wed, Feb 7, 2018 at 3:03 PM, Victor Olaya <vola...@gmail.com> wrote:
> 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, > can you confirm that a GRASS input/output parameter can solve their issue?. 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. > 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. > > Still OTB requires some changes in processing plugin to work. the old way of twisting application only for QGIS must be avoided. Without such a change there is no long-term existence even as plugin. Or worse, it exists and will be broken. 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. 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. Hence the idea of generic provider came up!. In case of GRASS its input/output parameter, for OTB it is selection list parameter. Thanks for your valuable feedback on this. I am sure an idea of generic provider came up sometime during your work on processing plugin. It tough and need more expert work and safe is to avoid it totally. I agree on that part. > 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. > > Cheers > > > > 2018-02-07 14:41 GMT+01:00 Rashad Kanavath <mohammedrasha...@gmail.com>: > >> Hello victor, >> >> Do you see a possibility of a generic processing provider?. One that can >> read descriptor files and run algorithms!. >> 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!. >> Whichever toolbox want to be integrated into processing plugin can >> provide and maintain descriptor files individually. No QGIS developers need >> to be involved. >> This way, external toolboxes' team or qgis does not need to maintain/fix >> qgis-<TOOLBOX>-provider-plugin. >> >> search -> download -> install plugin will be changed to configure >> providers install location. >> If needed QGIS can control list of available providers (just names). >> >> External tools' dev team needs to know something such as spec of >> descriptor files, how to mention name of executable etc. >> They don't need to know stuff like how qgis run a processing algorithm, >> and things working of modeler, running with other algorithms. >> >> Anyway, this is just an idea and don't know what will be technically >> challenging issues? >> >> The other way of putting processing plugin into core and providers >> classified as external plugins can avoid maintenance on qgis. >> 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 >> Putting all stuff in qgis tree and taking no responsibility of providers >> isn't good either. >> >> This way, each team takes part and result in better collaboration and >> contribution. >> 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. >> >> >> On Wed, Feb 7, 2018 at 11:18 AM, Victor Olaya <vola...@gmail.com> wrote: >> >>> 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. >>> >>> 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? >>> >>> 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. >>> >>> Cheers >>> >>> >>> >>> 2018-02-06 18:57 GMT+01:00 Paolo Cavallini <cavall...@faunalia.it>: >>> >>>> Hi all, >>>> following the discussion on qgis-dev ML: >>>> https://lists.osgeo.org/pipermail/qgis-developer/2018-Januar >>>> y/051701.html >>>> it has been proposed to remove all external providers (namely OTB, >>>> already removed, GRASS, and SAGA) from Processing in QGIS2 (GDAL will >>>> remain as QGIS cannot be built without). This raised a number of >>>> concerns, so PSC decided not to rush removing them from the upcoming 3.0 >>>> release, and to open a wider discussions about this, involving all the >>>> interested parties, to find an optimal solution. >>>> If volunteers outside QGIS core team, ideally from the respective >>>> backends, could take the maintenance of these providers, not much would >>>> change for the end user. If not, this will mean effectively missing >>>> hundreds of algs from QGIS. >>>> I personally propose to reinstate the OTB plugin with Rashad (from OTB) >>>> as maintainer. >>>> QGIS.ORG will seek to support any decision made with funding where >>>> possible. >>>> Looking forward for your feedback. >>>> All the best. >>>> -- >>>> Paolo Cavallini - www.faunalia.eu >>>> QGIS & PostGIS courses: http://www.faunalia.eu/training.html >>>> https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis >>>> >>> >>> >> >> >> -- >> Regards, >> Rashad >> > > -- Regards, Rashad
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev