It's a project we were thinking about a couple of years ago, but the project has stopped (we've had to move the founds to other projects) The approach was similar to yours, but I was thinking to a lower level binding: let saga odules read directly from Qgis in memory data structures, without having to import/export data. In the latter case our doubt was: if we have to do that we already have the saga gui! We didn't see the gain in having a qt module... other than having to open saga gis.<div>
I haven't investigated this too much, and maybe it's a lot of work to do it (C++ code to be written, etc.), but it would give a great value to such a module. Don't you think?</div><div><br></div><div>Anyway, the first steps of having a python gui interface to saga-api is certainly foundamental.</div>
<div><br></div><div>giovanni<br><div><br>
<br><div class="gmail_quote">2011/2/17 Johan Van de Wauw <span dir="ltr"><<a href="mailto:johan.vandewauw@gmail.com" target="_blank">johan.vandewauw@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">On Thu, Feb 17, 2011 at 1:27 AM, Volker Wichmann <span dir="ltr"><<a href="mailto:wichmann@laserdata.at" target="_blank">wichmann@laserdata.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
Hi Gianluca,<br> My idea is to write a python code that will generate GUI<br>
dialogs completely on the fly without any hard coded parameter flags or<br>
.py files (SAGA has about 500 modules!). That is, you have a path where<br>
your SAGA modules (.so/.dll) reside and then your QGIS GUI will use the<br>
saga_api to generate the dialogs for the available modules on the fly.<br>
As far as I see, all you need is the following information:<br>
* module library name<br>
* module name<br>
* module (saga_cmd) parameter names<br>
* module parameter types<br></blockquote><div>That seems the best approach to me as well. I've attached a script which creates a saga_cmd call for most modules, which I once used to check if there are any obvious errors/memory leaks. As mentioned before, this script is the first thing I wrote in python, so sorry for any strange unnecessary constructions and/or errors, but it should give you an idea how to browse through the module libraries, modules and their parameters.<br>
<br></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br>
All you would need is a generic python module which would generate the<br>
dialogs for QGIS using the saga_api on the fly and another python module<br>
which would use the information entered in these QGIS dialogs to call<br>
saga_cmd. But maybe I'm getting this wrong.<br></blockquote><div> </div><div>Prior to jumping towards dialogs, perhaps it is useful to think about how you want to integrate saga and qgis:<br>* how are module libraries and modules presented? In a menu or some type of module library?<br>
* which qt interface would you like to use to present the different type of parameters that saga has. This is really an important decision. I personally think that the way saga relies heavily on wxpropgrid to generate its interfaces is really nice. Someone who knows qt well may give some advice here what the best approach would be. If some kind of property grid is already used in qgis, I would certainly look to that. I really think this is one of the most important decisions - some modules have a lot of different parameters (eg [2]) and presenting them in an orderly way is quite a challenge.<br>
* which types of modules would you like to provide first? Shape or grid based modules?<br>* how do you handle file conversions? Eg a geotiff is open in qgis. Prior to running this module, it will have to be converted to a .sgrd file (can be done with gdal)? <br>
<br>In fact, if I would be starting this project, I would use this approach:<br>1. Create some type of menu/module library to show the saga modules<br>2. If these are opened show a very basic window showing a generated command line and a html box with the documentation of the module (eg [2]). At that point, you actually have nothing more than a nice way to browse through the saga modules from qgis, without any integration. But it offers a starting point. <br>
3. If a good approach is found to generate the kind of property grid, you could switch to having a text box per parameter type. In a next step, some options may be converted to better suited interfaces, eg showing a list of grids present in qgis. At this point, I think development can be done by different people: someone is working on an interface for shapefiles, someone else on file conversion issues/... At this point, knowledge of the saga api is less important, and most work is done in python/qt.<br>
<br></div></div>[1] <a href="http://www.saga-gis.org/saga_api_doc/html/parameters_8h.html#005312577c5ba61839e45f6a19b94218" target="_blank">http://www.saga-gis.org/saga_api_doc/html/parameters_8h.html#005312577c5ba61839e45f6a19b94218</a><br>
[2]<a href="http://www.saga-gis.org/saga_modules_doc/grid_analysis/grid_analysis_19.html" target="_blank">http://www.saga-gis.org/saga_modules_doc/grid_analysis/grid_analysis_19.html</a><br>
<br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">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>
<br></blockquote></div><br>
</div></div>