+1 for idea to create the core functionality of plugins into a more library like modules. And a good TIME to start of with this too, thanks for raising this Nyall!
What I miss in Processing though (but I'm not sure if it should be introduced in processing!) is the intelligent gui you sometimes need for certain plugins.. Some examples: - a plugin which first has to access some REST-service to get a list of projects, then upon the selection of a project a dropdown is filled with 'modules' of which the user has to select one, and based on that...etc etc . and THEN the actual algorithm starts of. - a good geocoder: off course the actual sending of the final request and parsing/showing the response is a nice processing component, but the first interaction with the user (like autocompletion etc) to mee seems more a gui/plugin thing What (I think) makes a distinction between a plugin and a processing one, is that a plugin offers a complex interaction with the user (so gui interaction) , while in processing the algorithm is the actual center of gravity. But maybe I'm wrong in this analysis. Looking at my own plugins, it is often the gui-interaction which (for me) makes it harder to me to move it to processing... Could/would it help if we create a common interface both for plugins and processing? Or else, a plugin api-interface which more or less guides a dev in separating the gui-part into the plugin and the core part in a module/processing module? Only documentation and examples could have the same effect (AND are very much needed), but for example IF we already make the plugin builder create an 'api' should it not be more effective? As my gut feeling is a marriage between the plugin and processing parts is good(tm) :-) Regards, Richard Duivenvoorde On 12-09-16 06:51, Victor Olaya wrote: > +1 from me :-) (no surprise...) > > 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. > > 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... > > 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
