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.pire...@faunalia.it)
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer