[Qgis-developer] QGIS 3 plugins - require implementation as processing algs?

[Victor Olaya]

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.ml at 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.dawson at 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 at 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 at lists.osgeo.org
>> List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>