[Qgis-developer] fTools - Processing (again)

[Bernhard Ströbl]

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.

>   * Bugs need to be fixed twice

are they currently?

>   * Features need to be implemented twice

are they currently?

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
>> Qgis-developer at lists.osgeo.org
>> 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