Paolo, that sounds good to me The basic and experimental modules that you propose are the current simplified and advanced modes. We should work on a normal mode.
Let's discuss it here and maybe create a spreadsheet that we can edit to select the list of modules to include Thanks for the suggestions! 2014-06-23 19:06 GMT+02:00 G. Allegri <gioha...@gmail.com>: > I've given a look to the list of Processing QGIS geoalgorithms and I've > seen that all the tools from fTools seem to be there. I remembered that > someone was missing, but it seems not to be true anymore. I wonder if it > wouldn't be the case to drop fTools algorithms from Vector menu. It would > help in avoiding confusion, imho. > > giovanni > > > 2014-06-23 18:50 GMT+02:00 G. Allegri <gioha...@gmail.com>: > > Hi Paolo, >> I agree with you, a cleaner organization of Processing tools is advisable >> to reduce the confusion in users. >> It's rather difficult to teach them in a clear way too! :) >> >> IMHO this reorganization should consider also the integration of other >> sparse analysis/processing tools, like the ones under the Vector menu. I >> know it depends on their implemention (and its feasibility in the present >> Processing model), but it's one of the major sources of confusions or >> users. A typical question: why we have the Processing toolbox and a Vector >> menu, where some tools overlap, while other are only available under Vector >> menu, and so not usable inside a Processing model/workflow? >> >> I hope we will find time (=money) to close this gap and, hopefully, have >> most of the analysis tools under the same structure. Well... all but the >> C++ ones :( >> >> giovanni >> >> >> 2014-06-23 18:42 GMT+02:00 Paolo Cavallini <cavall...@faunalia.it>: >> >> Hi all. >>> We are thinking about the future of Processing framework. The >>> duplication shown among >>> modules is certainly a good thing, as it allows richer analyses and more >>> control and >>> verification, but can be intimidating even for skilled GIS users. >>> We have been discussed this before, but I came up with the conclusion >>> that a >>> reasonable approach would be to have three levels: >>> * basic - only one choice, no overly complex modules >>> * normal - all well tested modules, minimizing duplication >>> * experimental - out in the wild, all modules. >>> This would improve the user experience, and would require less >>> maintenance by core devs. >>> Of course the selection of the modules for the second category is rather >>> complex, and >>> would require much thinking. >>> Opinions? >>> All the best. >>> -- >>> Paolo Cavallini - www.faunalia.eu >>> Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html >>> _______________________________________________ >>> Qgis-developer mailing list >>> Qgis-developer@lists.osgeo.org >>> http://lists.osgeo.org/mailman/listinfo/qgis-developer >>> >> >> >> >> -- >> Giovanni Allegri >> http://about.me/giovanniallegri >> Twitter: https://twitter.com/_giohappy_ >> blog: http://blog.spaziogis.it >> GEO+ geomatica in Italia http://bit.ly/GEOplus >> > > > > -- > Giovanni Allegri > http://about.me/giovanniallegri > Twitter: https://twitter.com/_giohappy_ > blog: http://blog.spaziogis.it > GEO+ geomatica in Italia http://bit.ly/GEOplus > > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer