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 > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
