* Nyall Dawson <[email protected]> [2019-02-07 17:05:14 +1000]:
On Thu, 7 Feb 2019 at 01:41, Nikos Alexandris <[email protected]> wrote:
2) For the Processing Toolbox, my understanding is that it requires
significant effort to reflect the logic of a GRASS GIS module using
QGIS' Processing interface to GRASS GIS. Am I wrong?
If I go for the Processing option, however, is it possible to inegrate a
GRASS GIS add-on under the QGIS' Processing GRASS provider, at run-time?
Essentially, is it possible to write (new) "description" files under
`python/plugins/processing/algs/grass7/description/` which are likely
placed under directories owned by the root/admin user?
If none of the above can ensure access to a GRASS GIS add-on through
QGIS, one that is to be installed using `g.extension` after having
installed QGIS and GRASS GIS, what would you then recommend?
My recommendation:
I would implement expose your GRASS add-on as its own processing
provider. You would base this almost entirely off the existing
processing grass provider, but with its own set of description files
exposing only your add on modules. You should be able to do this by
importing the existing grass provider classes, and overwriting the
provider code to have a new ID/name/icon/etc.
This would also make it easy to redistribute - you'd wrap your
provider into a plugin, and then could distribute via the normal
plugin channels. And if you do it right (and only import existing
processing grass code, minimising the copy/paste of this code), then
you're provider will automatically inherit any future fixes and
features added to the main grass provider.
Dear Nyal,
thank you for your time and the recommendation. I guess this is
currently the only reasonable approach to distribute the "provider" and the
plugin.
Kind regards, Nikos
_______________________________________________
grass-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-dev
