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

[Martin Dobias]

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.

Regards
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20121121/497b5cc0/attachment-0001.html>