[Qgis-developer] Reliable way to determine a groupIndex in the legend tree

[Gino Pirelli]

I'm reading this thread in a too fast way so probably I'll miss something

we can distinguish two topics in this thread

1) api re-design... but I think is a Architecture re-design of the
QgsLegend component
2) Enhancement of the Legend interface.

Thread 1) more technical, at this moment is still not approached
Thread 2) is focused (as I understood) on adding a new type of ItemGroup
that would manage a mutual/exclusive selection (radio button mode selection
inside the group)
Thread 3) please add topic of this thread if I missed it.

I can say something about Thread 1) that is related with Thread 2).
Sorry if I make mistakes on this my analysis, I tried to the do the best I
can and I'm here to learn :)
At this moment QgsLegend doesn't use a clear MVC pattern (
http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller). This
is (probabily) the main problem to expand it's features. I'm not sure about
group managing because I didn't focus on this feature, but I'm quite sure
that Item customization limits are extended to groups too.
QgsLegend is based on QTreeView that has all features to allow a full
customization of it's items (a group is a kind of item).
The main problem at this moment is that rendering of an item is not
delegated to each item but it's spread in different classes that create an
abstraction of the different kind of items.
I found this limitations looking for a solution to show WMS legends in
legend interface.
I my different way to find a solution to this new feature I also tried to
add a "delegation"approach (just to try if it was feasible) but I wasn't
able to have a complete control of the item rendering... this is seems be
related with not so clear (to me) path of emitted signal inside this
hierarchy of classes.

So my conclusion are
1) move all rendering action custom item delegates
2) clean or clarify signals emitted and inter-relation with the classes of
the legend ecosystem.
3) this is a "new" point... I think that to allow developing new feature
it's necessary create and abstraction of the data returned by
layer->legendSymbologyItems() because returning a QList< QPair< QString,
QColor > > is a really a big limitation to customization (for example I
can't ask to the layer to return a pixmap that is the legend for a WMS
layer)

Why thread 1) is related with Tread 2)? because if I've a clear Item
delegation I can add a new group item that manage it's rendering and
behavior basing on it's own characteristic.

I hope to hear from who's more "inside" qgis architecture to find the
"correct" direction.

thank you, Luigi Pirelli (luigi.pirelli at faunalia.it)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20131013/a06b88b7/attachment.html>