During the Girona hackfest, I added a new functionality, to create a plugin with a Processing provider, directly from the toolbox. You just create a bunch of Processing scripts (unless the algorithm is really complex, it should be possible and easier to add it as a script), and then select them and create a provider plugin with them.
This is done using the "Scripts/Tools/Create script collection plugin" option in the Processing toolbox. If you want to create this kind of plugin (based on Processing scripts) manually, the Processing code includes and example [1]. It also includes an example of a "normal" plugin with an algorithm provider, similar the the one that Vincent Mora wrote [2] This is (briefly) documented in [3] If you have ideas about how to give more visibility to these docs, let us know. Paolo and I discussed this a bit after Girona, but I guess we can make all this more visible and accesible for developers. I will be happy to extend those documents with ideas, so feel free to propose improvements. Cheers [1] https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/examplescripts [2] https://github.com/qgis/QGIS/tree/master/python/plugins/processing/algs/exampleprovider [3] http://docs.qgis.org/testing/en/docs/pyqgis_developer_cookbook/processing.html 2016-09-12 7:02 GMT+02:00 Vincent Picavet (ml) <vincent...@oslandia.com>: > 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