Hello, On 12/09/2016 06:51, Victor Olaya wrote: > +1 from me :-) (no surprise...) +1 from me here, this is something we push forward as soon as we have the opportunity.
> I will be happy to help on this, helping developers when adapting > their plugins. I can even make a short list in advance, with the > current plugins that would be convenient to adapt as Processing > algorithms, and help their developers implement them as such. Having a better documentation and howto on "write QGIS Processing Plugins" could be interesting. Vincent Mora wrote a minimal Processing Plugin for educational purpose, it could be used as a starter. https://github.com/vmora/micro-processing More templates from Plugin Builder could also be interesting. > I think most people will agree, since I am aware that many like the > idea and if they havent done it it is because they had no time or > didnt know how to do it, but we can expect some people to protest and > refuse. I guess we have to take that into account, since it is also > not nice to make our users and plugin devs angry... If we have documentation and howtos, I think we can be a bit pushy on this topic, since plugin developers will have to modify their code anyway. And if they do not want to do it, they can still publish their plugin outside of the main repository. Vincent > > Let me know how I can help on this. > > Cheers > > > > 2016-09-12 1:31 GMT+02:00 Nyall Dawson <nyall.daw...@gmail.com>: >> Hi all, >> >> Just something which has been on my mind and I thought I'd see if others >> agree: >> >> Given that for QGIS 3.0 we will effectively start the available plugin >> repo with a "clean slate", I'm wondering if it's a good time to put in >> a restriction along the lines: >> >> "If it COULD be made as a processing algorithm then it MUST be made as >> a processing algorithm". >> >> This is leading from Victor's excellent talk at Girona >> (http://diobma.udg.edu/handle/10256.1/4300) But basically, there's >> many reasons why we'd want this, including: >> >> - consistent, robust and featureful UI for algorithms. Instead of >> every plugin implementing its own UI with a different feel and feature >> set, all processing algorithms have a consistent UI, which is well >> tested and stable. This also makes things easier for plugin devs in >> that they no longer have to waste time with UI, and they gain all the >> extra features which are available in the processing UI (eg extent >> selection with options from canvas, layers, etc) at no cost to >> themselves. >> >> - plugins become instantly more useful because they can be integrated >> into models. This is better for users since these plugin algorithms >> become more powerful. It's also better for plugin devs since their >> plugins will get more use. >> >> - easier path for valuable, widely used algorithms to become part of >> core processing - if plugins are developed using the processing >> algorithm framework then it becomes much easier for us to pull them >> into the core qgis algorithms. >> >> - better interface for QGIS. Instead of power users getting bogged >> down with dozens of extra toolbar icons and menus for every plugin >> they've installed they would instead be nicely and consistently >> grouped into the processing toolbox. >> >> (But seriously - watch Victor's presentation. He explains this all much >> better!) >> >> Given this, should we require that for any plugin to be eligible to be >> included in the official repo it MUST be implemented as a processing >> algorithm IF it can be be fully implemented as an algorithm? >> >> I personally can only see benefits to this approach, and timing it >> with 3.0 (when people have to rewrite their plugins anyway) makes >> sense. >> >> Thoughts? >> >> Nyall >> _______________________________________________ >> Qgis-developer mailing list >> Qgis-developer@lists.osgeo.org >> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
