[Qgis-developer] acecss to qgisapp / qgisappinterface from tests (c++ or python?)

[Etienne Tourigny]

Hi,

I have worked on implementing this, please give me any comments.

https://github.com/etiennesky/Quantum-GIS/tree/browser_scanitems

There a few few things missing (like error messages) and a few rough
edges, but it works for opening vector, raster and zip datasets in
commandline, file open as well as file browser.
I have not tested for providers other than gdal and ogr.

Etienne

On Thu, Nov 22, 2012 at 2:11 PM, Etienne Tourigny
<etourigny.dev at gmail.com> wrote:
> Hi,
>
> I followed your suggestion and created a QgsDataSource class, which
> has been sub-classed in ogr and gdal providers (with just a tad more
> definitions).
>
> I could use another piece of advise...
>
> The app opens a dialog when there are sublayers, so the user can
> choose which layer(s) are to be opened.
>
> Ideally this should be called without too much effort, and the
> following approaches could be used:
>
> - add a gui class to get selected layers, takes as argument the QgsDataSource
> - run this automatically from QgsDataSource (or the provider
> subclasses) - but this would require a dependency on qgis_gui which is
> not cool for core/provider. Also may not be advisable for simple
> queries.
>
> any thoughts?
>
>
> Also one more point...
>
> Data sources inside zip/tar files are supported in qgis through the
> VSIFILE mechanism from gdal/ogr.
> A zip file can contain a mixture or vector/raster files so I was
> thinking of creating a (small and simple) provider for handling these
> files, since they should not be handled by both (gdal and ogr)
> providers for detecting valid datasets.
> Returned sublayers list couls be a mixture of vector/raster datasets,
> easily opened through full uri.
>
> Also vsifile allows for many other "virtual" files such as remote
> files (http/ftp) using /vsicurl/url_to_file syntax
> Qgis could be extended eventually to support these other VSIFILE
> types, hence the argument to make it a provider.
>
> More information on VSIFILE:
> http://trac.osgeo.org/gdal/wiki/UserDocs/ReadInZip
> http://www.gdal.org/cpl__vsi_8h.html
>
>
> Etienne
>
> On Wed, Nov 21, 2012 at 10:41 AM, Martin Dobias <wonder.sk at gmail.com> wrote:
>>
>> On Wed, Nov 21, 2012 at 12:14 PM, Etienne Tourigny <etourigny.dev at gmail.com>
>> wrote:
>>>
>>> I agree that it would be good to implement this idea.  However it
>>> requires a few changes in the API.
>>>
>>> Could this be done before 2.0, or after?  As it won't cause breakage
>>> it probably would be ok to add afterwards. But I think that if it's
>>> done after 2.0 not many plugins will use it.
>>> However, this would probably be low in the priorities so it probably
>>> won't make it.
>>
>>
>> Both options are possible and I would be in favour of having it earlier than
>> later... maybe it will become apparent that some breakage would be useful,
>> so it would not need postponing until 3.0.
>>
>> Anyway regarding usage of new APIs in plugins, I wouldn't be afraid that
>> plugin writers would not pick up new APIs. We have been introducing new APIs
>> in 1.x releases quite often and people could decide whether they will prefer
>> convenience of new APIs or compatibility with old versions.
>>
>>
>>> I was perhaps thinking of a less complex way - a function which
>>> returns a vector of QgsMapLayer given an uri, to replace
>>> QgisApp::addMapLayers() but that is available outside of QgisApp.
>>> Also the same for addVectorLayer() and addRasterLayer() (returning a
>>> list of vector and raster layers, resp.)
>>
>>
>> Isn't such function just a step away from a simple data source class?
>> Because such function would be provider-specific anyway...
>>
>>
>>> Then this code could be migrated to proper QgsVectorDataSource /
>>> QgsRasterDataSource when possible.
>>>
>>> Which class could this go into?
>>
>>
>> As a temporary solution you could just create a static method in
>> QgsOgrProvider class and create a unit test in c++ (as it would not be
>> available from python). But I would really like to encourage you to start
>> with data sources :-) The interface in the beginning could be as simple as:
>>
>> class QgsDataSource
>> {
>> public:
>>   static QgsDataSource* open( QString baseUri, QString provider );
>>
>>   QStringList layerNames() = 0;  // get list of sub-layers
>>   QString uriForLayer( QString layerName ) = 0; // return full provider URI
>> for a particular sub-layer
>> };
>>
>> OGR provider would have its QgsDataSource implementation,
>> QgsDataSource::open(path, "ogr") would simply create an instance of OGR's
>> implmentation.
>
> ah ok I thought you meant having a container for various layers - but
> you mean a wrapper for the layer URIs that are inside a given data
> source.
>
>>
>> Regards
>> Martin