[Qgis-developer] Legend group API

[Sandro Santilli]

On Tue, Dec 11, 2012 at 12:02:57PM +0100, Andreas Neumann wrote:

> I would like to see such an improved legend interface. Currently the
> group and layer index even behaves differently between version 1.8
> and version 1.9. I have to check the version and decrease the index
> in case it is version 1.9.
> 
> I use this horrible code to find a group and attach a new layer:
> 
> --------------------
> 		#get the current group index of Schüler group
> 		groups = []
> 		for group in self.legend.groupLayerRelationship():
> 			groups.append(group[0])
> 		groupIndex = groups.index(groupName)
> 		#move new layer to existing group
> 		if QGis.QGIS_VERSION[0:3] >= "1.9":
> 			groupIndex -= 1
> 		self.legend.moveLayer(schoolDistrictLayer, groupIndex)
> -------------------
> 
> Really horrible - this really should be a one-liner ... and not a
> different behavior between QGIS versions for no good reason.

Indeed. Well, oneliner it could become by simply exposing
a findGroupIndexByName kind of method, but I think the confusion
here is about the semantic associated with such "group index"
variable.

In my case I've had to do with addGroup returning a "groupIndex"
and moveLayer taking a "groupIndex" but those functions giving
a different meaning to the "groupIndex" concept.

It's more about documentation than anything else.

I think Martin ideas is sensible and I do see the code is going
in that direction. But even if the classes are decoupled from
the QT tree widget we'll need a way to identify groups, as much
as we do with layers (which do have an ID). I've no problem with
all elements (be them layers or groups or whatever) share the
same "id space" but each one should have an identifier which
remains valid for the whole lifetime of that object.

Could very well be a pointer, at the C++ level (altought there's
currently no moveLayer method taking a Group pointer), but keeping
an integer is also fine, if it helps keeping the API small and
stable.

--strk;