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

[Victor Olaya]

+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.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