Interesting. Let me bring my relative outsider's and newcomer's view
into this. Although a long time QGIS user, I've never really dug into
the Processing tools.
I'm working on a project, where one part is a plugin - mostly a
relatively simple set of dialogs that integrate with other parts of t
On 02/06/2017 01:24 AM, Paolo Cavallini wrote:
> Il 06/02/2017 10:21, Victor Olaya ha scritto:
>
>> Just let make sure that we have some clear acceptance criteria (algs
>> with tests, trying to follow some "best practices" and using
>> Processing methods when possible, etc).
>
> right, what could
Hi
> On 06 Feb 2017, at 12:35 PM, Victor Olaya wrote:
>
>
> One thing I am concerned about is that we guarantee some stability in the
> behavior of processing. While it is true that strictly speaking new
> algorithms do not represent API extensions / additions, in some level I think
> they d
>
>
> One thing I am concerned about is that we guarantee some stability in the
> behavior of processing. While it is true that strictly speaking new
> algorithms do not represent API extensions / additions, in some level I
> think they do since anyone using Python + Processing will be vulnerable t
On 6 February 2017 at 19:21, Victor Olaya wrote:
> Very interesting question...
>
> IMHO, all plugins that include processing algorithms like that (just
> one of them or a few of them, using only native code), we should ask
> developers to put the code in the central QGIS repo, and then work on
>
Hi
> On 06 Feb 2017, at 11:21 AM, Victor Olaya wrote:
>
> Very interesting question...
>
> IMHO, all plugins that include processing algorithms like that (just
> one of them or a few of them, using only native code), we should ask
> developers to put the code in the central QGIS repo, and then
Il 06/02/2017 10:21, Victor Olaya ha scritto:
> Just let make sure that we have some clear acceptance criteria (algs
> with tests, trying to follow some "best practices" and using
> Processing methods when possible, etc).
right, what could be the procedure then? whan I see a submitted pluygin
tha
Very interesting question...
IMHO, all plugins that include processing algorithms like that (just
one of them or a few of them, using only native code), we should ask
developers to put the code in the central QGIS repo, and then work on
that through PRs. It makes more sense. In the case of a plugi
Il 06/02/2017 00:55, Nyall Dawson ha scritto:
> What I'm wondering now is whether we should be merging functionality
> like this into master.
+1, thanks for raising this.
> - might be a good spring-board for easing plugin developers into
> working with the master repo. There's a chance they'll f
Hi all,
Just wanted to raise a question I've been pondering lately.
Thanks to the success of the processing plugin, we're now seeing a lot
of 3rd party plugins which implement their functionality as processing
providers. (This is a great thing and hopefully we see more of this
when people port th
10 matches
Mail list logo
