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

[Etienne Tourigny]

Hi

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.

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.)

Then this code could be migrated to proper QgsVectorDataSource /
QgsRasterDataSource when possible.

Which class could this go into?

Etienne

On Tue, Nov 20, 2012 at 9:45 PM, Martin Dobias <wonder.sk at gmail.com> wrote:
>
> On Tue, Nov 20, 2012 at 6:16 PM, Etienne Tourigny <etourigny.dev at gmail.com>
> wrote:
>>
>>
>> Unfortunately the code that handles sublayer loading is in QgisApp,
>> and I would like to add some tests for this in case it gets broken in
>> the future. It broke a few months ago for rasters, and there ia a case
>> where it doesn't work for vectors.
>>
>> Would you have a suggestion as to how we can improve this - i.e.
>> manage sublayers outside of QgisApp?
>
>
> I think the sublayer handling should be done at the provider level. What is
> currently missing in QGIS is a notion of collection of layers. For example,
> OGR has "data sources" (usually a directory, server connection etc) which
> can be used for listing and accessing sublayers in a generic way - we need
> something like this also for QGIS provider implementations. Some providers
> already have some code going into this direction, but it's not exposed under
> a common API (e.g. QgsVectorDataSource class) - there is QgsPostgresConn or
> QgsSpatiaLiteConnection.
>
> The support for data sources would be also very handy for generic operations
> on layers (create, remove, rename).
>
> Regards
> Martin
>