[Qgis-developer] fTools - Processing (again)

[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)
 * Bugs need to be fixed twice
 * Features need to be implemented twice

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
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer