On 1 February 2018 at 20:01, Rashad Kanavath <[email protected]> wrote: > Hello, > > Processing plugin allows to integrate other toolboxes. IIUC, this was one of > the features of it. > So when you say integration of so and so toolboxes are total mess, you might > think back.
I think there's a misunderstanding/language barrier at play here - no-one meant that the code is a mess, just that the end result of the QGIS team trying to maintain 3rd party providers resulted in an inferior experience all round - for users, qgis developers AND the underlying library developers (whom I'm sure don't appreciate being blamed when a QGIS processing algorithm is mis-using their API). Yes, one of Processing's big strengths is its ability to integrate other toolboxes and make 3rd party libraries accessible within the QGIS environment and tie them together into models. Another one of QGIS' great strengths is its strong plugin ecosystem, which allows anyone the ability to create plugins and extend QGIS, and not be tied into the core QGIS development practices and release schedules. That's why plugin-based providers are the BEST solution in my opinion. > Nobody had seen new changes to otb algs so all of your comments are on old > version. Why so rush? > Okay, it easy to reject stating the same reason over and over again. I > understand that. Just to be clear - no-one is commenting on your code quality or targeting OTB specifically. It's the question of whether or not Processing providers which depend on other libraries should be included in the main install or moved to plugins which we are debating. So please, don't take any of this as criticism of your code or (much appreciated) efforts. > What happens at end, a processing plugin with zero providers? Far from it. My vision would be: - core install: only includes the native QGIS providers (c++, Python and 3D) and the GDAL/OGR provider (since it's impossible to build QGIS without GDAL we can be 100% sure that it's always available wherever QGIS is installed). Maybe GRASS provider too, since GRASS is very heavily linked into QGIS due to the GRASS provider and c++ GRASS plugin. - via QGIS' plugin ecosystem: a whole world of providers ready to install for users, including SAGA, OTB, lastools, R, PySAL, etc... > Now the reason OTB had to maintain list of "supported" version is due the > fact that processing plugin does not allow to group parameters. > So the issue of a provider being total mess not fully related to provider > itself. If 90% of provider algorithm which you use, cannot be even > integrated into processing where will be the actual problem. I see a lot of > good changes in qgis processing and providers can greatly benefit from it > now. Can you elaborate on this please? I'm not aware what the "group parameters" issue is. > All those people blindly rejecting this proposal should have waited for new > changes. > I mean, I just put a proposal to lower the burden as much as possible. And > all those issues raised by Alex, Nyall and others will be considered in the > new diff. > Once I prepare changes, you can reject it!. You are voting -1ss on old > plugin code something I consider a mess to work with for both teams. Why? In the past we've always found that discussing plans upfront benefits everyone and prevents development effort in an approach which won't be accepted upstream. In summary, can you please outline the reasons why you think publishing this as a plugin is not ideal? Nyall _______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
