Hi Matthias,
sorry, I was not aware that new algorithms currently get implemented in
both, fTools and Processing (same for bug fixes). This may be because of
my ignorance, as I only adressed Processing with both, bug fixes and new
algorithms since it had been introduced.
Bernhard
Am 14.09.2015 um 09:48 schrieb Matthias Kuhn:
Hi Bernhard
On 09/14/2015 09:39 AM, Bernhard Ströbl wrote:
Hi Matthias,
Am 14.09.2015 um 09:31 schrieb Matthias Kuhn:
Hi Bernhard,
The current code redundancy does have some severe issues like:
* Algorithms may give different results from the vector menu and
processing (although both labelled similar, [QGIS] Geoprocessing)
I would need hints on tickets addressing such problems. If that is
really the case who is going to decide what the "right" result is?
Alternatively we could keep both but label them differently.
I don't know, maybe Paolo has some experiences?
For now, I would just dump one of the two implementations and if
problems surface decide case-by-case about the procedure (duplication or
introduction of an additional parameter).
* Bugs need to be fixed twice
are they currently?
* Features need to be implemented twice
are they currently?
My comments were targetting the current situation ;)
-- Matthias
Bernhard
If I remember right, somebody was working on a C++ implementation of
fTools recently. Does that ring a bell somewhere? It would be a pitty if
you work on this and a new implementation is merged at the same time.
After this question has been answered, a big +1 from my side to work on
this.
And another +1 if we get some unittests for the algorithms. They are
actually perfect candidates for unittests.
Kind regards
Matthias
On 09/14/2015 09:05 AM, Bernhard Ströbl wrote:
Hi Paolo,
just a thought: AFAIK fTools does not use 3rd party backends, so the
question of bulletproofness in conjunction with fTools IMHO should
only be raised for those algorithms that are currently in "QGIS
geoalgorithms". (Otherwise I fully agree: the rest should work
flawlessly)
As I said I would be willing to port what has not been ported yet
and/or look over algorithms that do not work as expected.
In spring the question of icons has been raised, too. This should not
be forgetten, either.
Bernhard
Am 11.09.2015 um 12:52 schrieb Paolo Cavallini:
Il 11/09/2015 11:29, kimaidou ha scritto:
+1 for this !
Hi all,
thanks for raising this point, IMHO a serious one. I'm very much in
favour of removing redundancy. In this case, however, I think we
better
be careful before removing fTools, because:
* people are used to it, and for one-shot analyses it is (slightly)
easier to run than Processing (weak argument)
* we do not have enough development resources to make Processing
bulletproof, particularly for 3rd party backends; therefore, we
encounter occasional problems, and we cannot guarantee a smooth user
experience in all cases (strong argument).
First issue can be solved, as suggested, by adding menu shortcuts to
Processing analyses, to mimic existing situation.
Second one is more serious: IMHO we really need a dedicated
developer in
this area: any power user (=larger institutions) are willing to
take it?
Similar things may be said for GDALTools.
All the best.
__________ Information from ESET Mail Security, version of virus
signature database 12248 (20150914) __________
The message was checked by ESET Mail Security.
http://www.eset.com
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
__________ Information from ESET Mail Security, version of virus
signature database 12248 (20150914) __________
The message was checked by ESET Mail Security.
http://www.eset.com
__________ Information from ESET Mail Security, version of virus signature
database 12248 (20150914) __________
The message was checked by ESET Mail Security.
http://www.eset.com
_______________________________________________
Qgis-developer mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/qgis-developer
