[Qgis-developer] Improving ftools geoprocessing tools

Victor Olaya volayaf at gmail.com
Thu Oct 22 06:59:27 PDT 2015


>>
>> Yep. I think the user-friendliness of ftools are that a/ algorithms
>> are offered in a simple and accessible menu items, and b/ the menu
>> item icons _greatly_ ease the understanding of what algorithms do.
>>


Icon support is already in Processing. The first versions actually
used the same ftools icons, but I removed that because there were new
algorithms being added, and it was quite messy to see some algorithms
with icons and others with the default icon. Instead, I started using
the same icon for all algorithms for a given provider, for the sake of
homogeneity.

However, the mechanism that I implemented for putting processing
algorithms in a menu allows to set an icon, so the current ftools menu
can be perfectly replicated, including icons

I copy here an example that  I added in another thread, about how to
replicate the Raster/Conversion  menu from Processing


import os
from GdalTools import GdalTools
from processing.gui.utils import addAlgorithmEntry
from PyQt4.QtGui import *

def addRasterAlgorithm(name, group, iconName):
    icon = QIcon(os.path.join(os.path.dirname(GdalTools.__file__),
"icons", iconName + ".png"))
    addAlgorithmEntry(name, "Raster", group, icon = icon)

addRasterAlgorithm("gdalogr:rasterize", "Conversion", "rasterize")
addRasterAlgorithm("gdalogr:translate", "Conversion", "translate")
addRasterAlgorithm("gdalogr:pcttorgb", "Conversion", "24-to-8-bits")
addRasterAlgorithm("gdalogr:rgbtopct", "Conversion", "8-to-24-bits")
addRasterAlgorithm("gdalogr:polygonize", "Conversion", "polygonize")

The addAlgorithmEntry is a part of Processing since quite a few
commits ago, and it allows to put an algorithm "outside" of the
toolbox, in a menu entry.

So the code is basically there, it is just a matter of finding out
which algorithms are missing and deciding where to call this methods
from. Then I guess we could use that funding to improve algorithms and
make them more robust and fast


Cheers




>> Both can be added to processing.
>>
>> On 22 Oct 2015 20:26, "Matthias Kuhn" <matthias at opengis.ch
>> <mailto:matthias at opengis.ch>> wrote:
>>
>>     Hi Giovanni,
>>
>>
>>     On 10/22/2015 02:38 PM, Giovanni Manghi wrote:
>>     > This users are
>>     > usually not able to handle (or willingly to) the possible
>>     problems of
>>     > using a toolbox based on other software.
>>
>>     There are a number of internal algorithms available in processing
>>     (i.e.
>>     no external dependencies).
>>     Unfortunately they are duplicates of ftools algorithms. But they have
>>     the advantage that they can be used in models.
>>     So if something is going to be improved it should be those - or we end
>>     up with a situation where we have fast algorithms in the menus but the
>>     same algorithm slower in the toolbox.
>>
>>     Therefore the plan of action should be:
>>
>>      * Create menu entries for often used (internal) processing algorithms
>>      * Remove ftools algorithms
>>      * Identify slow algorithms
>>      * Improve performance
>>
>>     This will solve João's problems in the most sustainable and effective
>>     way possible.
>>
>>     Chers
>>     Matthias
>>
>>
>>
>>     _______________________________________________
>>     Qgis-developer mailing list
>>     Qgis-developer at lists.osgeo.org <mailto:Qgis-developer at lists.osgeo.org>
>>     http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer


More information about the Qgis-developer mailing list