Hi,
Andreas Neumann wrote > 1. the method providing access to layers by name could return a list / > array with layer references - if the plugin author knows/assumes that > the layer names in his project are distinct he can just pick up the > first reference in the list Layer or groups ? Finding a layer in the legend is always possible even if there are another layer with the same name using legend.layers() that returns QList< QgsMapLayer * > and then is up to you to distinguish the layer. Andreas Neumann wrote > The current way to access the legend tree is complicated and not > developer friendly - .... Programmatically move a layer to a specified groups is not a common scenario but if you have to do that and you have nested groups there should be a way to uniquely index a group. Programmatically traversing the legend tree and keep track of its parent group is not a common scenario too and groupLayerRelationship can not help when there are groups with the same name. Andreas Neumann wrote > ....- and currently it is buggy (returns the wrong index). I don't want to be annoying but please consider the following simple legend example: - Layer1 - Group1 - Group2 --- NestedGroup3 - Group4 Suppose you want to use your test to move Layer1 in NestedGroup3 Your test code will fail and any other test will fail because self.legend.moveLayer in QGis 1.7 and 1.8 considers only top level group. I've introduced a different group indexing in 1.9 that is consistent with legend.groups() indexing. Now the same legend tree is indexed in the following manner: - Layer1 - Group1 [groupIndex=0] - Group2 [groupIndex=1] --- NestedGroup3 [groupIndex=2] - Group4 [groupIndex=3] that is consistent with the list returned by legend.groups() and give a consistent meaning to the groupIndex parameter used in the API documentation. I'm sorry for this drawback and I'm ready to contribute to a common solution that accommodates all the needs. In my case I need to : - load a third-party "workspace" file with a tree of groups and layers. - write a third-party "workspace" file with a tree of groups and layers starting from a qgis legend The main goal of the plugin I'm writing is to substitute a commercial solution (viewer + plugin) that is obsolete and expensive to maintain that is actually used by an Italian public administration. Massimo -- View this message in context: http://osgeo-org.1560.n6.nabble.com/index-in-self-legend-groupLayerRelationship-different-behavior-between-QGIS-1-8-and-master-tp5004337p5006367.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
