[Qgis-developer] fTools - Processing (again)

[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
>>> 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
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20150914/f40b5f76/attachment.pgp>