Hi Camilo.<div>I agree with your approach. I already expressed it in past emails on this topic.</div><div>Even if working at low levels requires some more overhead (cross platform builds and support), it would bring a higher level of usability.</div>
<div>A first step could be the design of data structures wrappers/bindings between ones.</div><div>I think that true integration between QGIS and SAGA internal native data structures.</div><div>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.</div>
<div><br></div><div>giovanni</div><div><br></div><div>[1] <a href="http://www.qgis.org/wiki/SAGA_Toolbox_for_QGIS">http://www.qgis.org/wiki/SAGA_Toolbox_for_QGIS</a></div><div><br><div class="gmail_quote">2011/3/30 Camilo Polymeris <span dir="ltr"><<a href="mailto:cpolymeris@gmail.com">cpolymeris@gmail.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hello, Paolo, and thanks for your swift answer.<br>
<br>
> Please do: I think this is quite interesting. Please note that Gianluca<br>
> Massei has started some work on this, so he may be able to start<br>
> quicker.<br>
<br>
Has Gianluca published his code? I'd like to see his approach and<br>
maybe work together. Mine is at github, BTW, but is completely<br>
unusable right now. Just experiments.<br>
<br>
> I think a C++ plugin has limited chances to be successful, because it<br>
> would either require a dependency of QGIS on SAGA, or the recompilation<br>
> of the plugin for each distro. Previous experiences in this direction<br>
> resulted in wonderful plugins used by very few people.<br>
> Python is the way to go IMHO.<br>
<br>
I may be wrong, but wouldn't a recompilation of the saga modules and<br>
saga API be necessary either way? Unless you install the full SAGA<br>
package. Even then, I am not sure if saga packages for all distros<br>
include the python bindings. These would have to be generated (SWIG)<br>
and compiled, too.<br>
Anyway, I was thinking more of a low level approach, dynamically<br>
loading the libraries and taking care of data structure exchange,<br>
which means this plugin wouldn't have the same requirements as most.<br>
<br>
> I think you should be able to complete the interface at least. Adding<br>
> all the modules may be postponed, if it proves too long. See the<br>
> GdalTools approach for this. Also the GRASS plugin should give you<br>
> insights.<br>
<br>
I'll try to identify the most used data structures and formats, see if<br>
there are some I can skip for now. Also I may leave out interactive<br>
modules, if necessary. Just to simplify things in the beginning.<br>
<br>
>> GUI: Any ideas? So far I think I'll just clone SAGA's.<br>
><br>
> I think it would be good if you could follow either the GdalTools or the<br>
> GRASS plugins approach.<br>
<br>
I will take a look at that, considering that I have to generate the<br>
interface on-the-fly based on module parameters and input data. I find<br>
specially SAGA's handling of interactive modules a little confusing:<br>
often it is not clear to the user (me, at least) what he is expected<br>
to do next.<br>
<br>
One of the difficulties I have faced is generated by SAGA's<br>
documentation. I thought I knew the API more or less well, but this<br>
new project as forced me to use parts I hadn't looked at before.<br>
<br>
Well, thanks again for your comments.<br>
<br>
Regards,<br>
Camilo<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>
</blockquote></div><br></div>