<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> I was suggesting this too, with the purpose to use the Executo (and the<br>
> whole Sextante plugin) from a CLI, i.e. a headless QgsApplication instance,<br>
> like Qgis Mapserver.<br>
<br>
</div>The problem is not there. That class has almost no GUI, except for a<br>
couple of message boxes.<br>
<br>
The problem is that SEXTANTE has to take the layers from somewhere,<br>
and now is connected to the QGIS interface to do so. SEXTANTE itself<br>
does not handle spatial data (does not open or save anything), but<br>
uses QGIS for that. This is mostly done through a class called<br>
QGisLayers, which could be replaced.<br></blockquote><div><br></div><div>Yes Victor, I've read your code quite extensively. Anyway, layers could also be managed through QgsMapLayerRegistry, yet I haven't investigated the differences betweend QgsMapLayerRegistry::mapLayers() [1] and QgsLegendInterface::layers [2].</div>
<div>Furthermore, you manage the load of layers from URI, so the layers can be loaded directly from source (and not as a layer instance already loaded in the Qgis GUI).</div><div>Anyway, I don't mean to remove the dependencies from Qgis. I only would consider an abstract approach that could handle both a headless Qgis instance, and a GUI based one.</div>
<div><br></div><div>[1] <a href="https://github.com/qgis/Quantum-GIS/blob/master/src/core/qgsmaplayerregistry.cpp#L173">https://github.com/qgis/Quantum-GIS/blob/master/src/core/qgsmaplayerregistry.cpp#L173</a> </div><div>
[2] <a href="https://github.com/qgis/Quantum-GIS/blob/master/src/gui/qgslegendinterface.h#L59">https://github.com/qgis/Quantum-GIS/blob/master/src/gui/qgslegendinterface.h#L59</a></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I however, think that it will not be so easy, since there are a few<br>
other places where SEXTANTE is linked to QGIS. Anyway, I belive is<br>
better to concentrate on the current version and work, and then move<br>
to that. i have tried to keep things independent, so it will not be<br>
too hard if we keep on developing code that is not directly linked to<br>
QGIS elements<br></blockquote><div><br></div><div>Absolutely Victor. These were just thoughts for the future, but that in case you agree they could help to avoid heavy, direct, bindings to the GUI environment that could raise in future developments.</div>
<div><br></div><div>I admit it: I'm thinking about a Qgis WPS server ;)</div><div><br></div><div>giovanni</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Regards<br>
<span class="HOEnZb"><font color="#888888"><br>
Victor<br>
</font></span></blockquote></div><br>