Hi Gianluca, I can't say how much I could dedicate to that, but if you could put it on GitHub I could find some time to contribute. I don't think I can invest time on the low level development, but with Python I think I could give some time.
giovanni 2011/3/31 gianluca.massei <g_ma...@libero.it> > hi camilo, I'm working to make a qgis-saga interface me too, but with a > "python approach". I haven't published my code because it's very > experimental and really not usable. Anyway, at moment I can access from QGIS > to saga via a simple menu. After the call, each module print to stdout the > "help" output (like "saga_cmd library_name module name -h"). I'm working to > build GUI "on the flay" with pyQT but progress is really slow. > If you think to use python I'm happy to work togheter and I'll put my > rough code on GitHub. Otherwise, don't know C++ enough to really contribute > at the develop of plugin. > > Hi > > Gianluca > > > Il 30/03/2011 13.16, Camilo Polymeris ha scritto: > > Hello, Paolo, and thanks for your swift answer. >> >> Please do: I think this is quite interesting. Please note that Gianluca >>> Massei has started some work on this, so he may be able to start >>> quicker. >>> >> Has Gianluca published his code? I'd like to see his approach and >> maybe work together. Mine is at github, BTW, but is completely >> unusable right now. Just experiments. >> >> I think a C++ plugin has limited chances to be successful, because it >>> would either require a dependency of QGIS on SAGA, or the recompilation >>> of the plugin for each distro. Previous experiences in this direction >>> resulted in wonderful plugins used by very few people. >>> Python is the way to go IMHO. >>> >> I may be wrong, but wouldn't a recompilation of the saga modules and >> saga API be necessary either way? Unless you install the full SAGA >> package. Even then, I am not sure if saga packages for all distros >> include the python bindings. These would have to be generated (SWIG) >> and compiled, too. >> Anyway, I was thinking more of a low level approach, dynamically >> loading the libraries and taking care of data structure exchange, >> which means this plugin wouldn't have the same requirements as most. >> >> I think you should be able to complete the interface at least. Adding >>> all the modules may be postponed, if it proves too long. See the >>> GdalTools approach for this. Also the GRASS plugin should give you >>> insights. >>> >> I'll try to identify the most used data structures and formats, see if >> there are some I can skip for now. Also I may leave out interactive >> modules, if necessary. Just to simplify things in the beginning. >> >> GUI: Any ideas? So far I think I'll just clone SAGA's. >>>> >>> I think it would be good if you could follow either the GdalTools or the >>> GRASS plugins approach. >>> >> I will take a look at that, considering that I have to generate the >> interface on-the-fly based on module parameters and input data. I find >> specially SAGA's handling of interactive modules a little confusing: >> often it is not clear to the user (me, at least) what he is expected >> to do next. >> >> One of the difficulties I have faced is generated by SAGA's >> documentation. I thought I knew the API more or less well, but this >> new project as forced me to use parts I hadn't looked at before. >> >> Well, thanks again for your comments. >> >> Regards, >> Camilo >> _______________________________________________ >> 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 >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer