<div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 23, 2014 at 11:28 AM, Alexander Bruy <span dir="ltr"><<a href="mailto:alexander.bruy@gmail.com" target="_blank">alexander.bruy@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Giovanni,<br>
<br>
some time ago not all FTools modules were available via Processing, but we add<br>
at least part of missed modules to it (e.g. Random Points algs were added about<br>
month ago with Faunalia support). Unfortunately if I'm not wrong<br>
several algorithms<br>
still missed (for example Vector Grid).<br>
<br>
But I agree, when all FTools (and maybe GDAL Tools) algs will be<br>
available via Processing<br>
we should drop them and keep only Processing.<br></blockquote><div><br></div><div>+1 However, I think the menu items should stay for at least one release. The FTools/GDALTools plugins can be dropped and the associated menu items in each menu can instead interface with Processing, triggering a call to the appropriate algorithm's GUI.<br>
<br></div><div>In addition, there could be a non-blocking QgsMessageBar that quickly notifies the user that some items in the menus will be going away, and to start using Processing more.<br><br>Forcing everyone to immediately switch (by removing those menu items) may be a bit harsh. (I can just see all the issue tickets about missing menus.) Also, gives time for the docs to catch up with the change, before the menu items are removed.<br>
<br></div><div>Regards,<br><br></div><div>Larry<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2014-06-23 19:50 GMT+03:00 G. Allegri <<a href="mailto:giohappy@gmail.com">giohappy@gmail.com</a>>:<br>
<div class="HOEnZb"><div class="h5">> Hi Paolo,<br>
> I agree with you, a cleaner organization of Processing tools is advisable to<br>
> reduce the confusion in users.<br>
> It's rather difficult to teach them in a clear way too! :)<br>
><br>
> IMHO this reorganization should consider also the integration of other<br>
> sparse analysis/processing tools, like the ones under the Vector menu. I<br>
> know it depends on their implemention (and its feasibility in the present<br>
> Processing model), but it's one of the major sources of confusions or users.<br>
> A typical question: why we have the Processing toolbox and a Vector menu,<br>
> where some tools overlap, while other are only available under Vector menu,<br>
> and so not usable inside a Processing model/workflow?<br>
><br>
> I hope we will find time (=money) to close this gap and, hopefully, have<br>
> most of the analysis tools under the same structure. Well... all but the C++<br>
> ones :(<br>
><br>
> giovanni<br>
><br>
><br>
> 2014-06-23 18:42 GMT+02:00 Paolo Cavallini <<a href="mailto:cavallini@faunalia.it">cavallini@faunalia.it</a>>:<br>
><br>
>> Hi all.<br>
>> We are thinking about the future of Processing framework. The duplication<br>
>> shown among<br>
>> modules is certainly a good thing, as it allows richer analyses and more<br>
>> control and<br>
>> verification, but can be intimidating even for skilled GIS users.<br>
>> We have been discussed this before, but I came up with the conclusion that<br>
>> a<br>
>> reasonable approach would be to have three levels:<br>
>> * basic - only one choice, no overly complex modules<br>
>> * normal - all well tested modules, minimizing duplication<br>
>> * experimental - out in the wild, all modules.<br>
>> This would improve the user experience, and would require less maintenance<br>
>> by core devs.<br>
>> Of course the selection of the modules for the second category is rather<br>
>> complex, and<br>
>> would require much thinking.<br>
>> Opinions?<br>
>> All the best.<br>
>> --<br>
>> Paolo Cavallini - <a href="http://www.faunalia.eu" target="_blank">www.faunalia.eu</a><br>
>> Corsi QGIS e PostGIS: <a href="http://www.faunalia.eu/training.html" target="_blank">http://www.faunalia.eu/training.html</a><br>
>> _______________________________________________<br>
>> Qgis-developer mailing list<br>
>> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Giovanni Allegri<br>
> <a href="http://about.me/giovanniallegri" target="_blank">http://about.me/giovanniallegri</a><br>
> Twitter: <a href="https://twitter.com/_giohappy_" target="_blank">https://twitter.com/_giohappy_</a><br>
> blog: <a href="http://blog.spaziogis.it" target="_blank">http://blog.spaziogis.it</a><br>
> GEO+ geomatica in Italia <a href="http://bit.ly/GEOplus" target="_blank">http://bit.ly/GEOplus</a><br>
><br>
> _______________________________________________<br>
> Qgis-developer mailing list<br>
> <a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
<br>
<br>
<br>
--<br>
</div></div><span class="HOEnZb"><font color="#888888">Alexander Bruy<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</div></div></blockquote></div><br></div></div></div>