Hi Camilo. I agree with your approach. I already expressed it in past emails on this topic. Even if working at low levels requires some more overhead (cross platform builds and support), it would bring a higher level of usability. A first step could be the design of data structures wrappers/bindings between ones. I think that true integration between QGIS and SAGA internal native data structures. Here [1] we started a discussion page. I couldn't go on with this project because the company decided to not invest on it now, but I'm still interested on it.
giovanni [1] http://www.qgis.org/wiki/SAGA_Toolbox_for_QGIS 2011/3/30 Camilo Polymeris <cpolyme...@gmail.com> > 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