<div dir="ltr"><div class="gmail_extra">I'm reading this thread in a too fast way so probably I'll miss something</div><div class="gmail_extra"><br></div><div class="gmail_extra">we can distinguish two topics in this thread</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">1) api re-design... but I think is a Architecture re-design of the QgsLegend component</div><div class="gmail_extra">2) Enhancement of the Legend interface.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">Thread 1) more technical, at this moment is still not approached</div><div class="gmail_extra">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)</div>

<div class="gmail_extra">Thread 3) please add topic of this thread if I missed it.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I can say something about Thread 1) that is related with Thread 2).</div>

<div class="gmail_extra">Sorry if I make mistakes on this my analysis, I tried to the do the best I can and I'm here to learn :)</div><div class="gmail_extra">At this moment QgsLegend doesn't use a clear MVC pattern (<a href="http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller">http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller</a>). 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.<br>

</div><div class="gmail_extra">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).</div><div class="gmail_extra">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.</div>

<div class="gmail_extra">I found this limitations looking for a solution to show WMS legends in legend interface.</div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">So my conclusion are</div><div class="gmail_extra">1) move all rendering action custom item delegates</div><div class="gmail_extra">2) clean or clarify signals emitted and inter-relation with the classes of the legend ecosystem.</div>

<div class="gmail_extra">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)</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra"><br></div><div class="gmail_extra">I hope to hear from who's more "inside" qgis architecture to find the "correct" direction.</div><div class="gmail_extra"><br></div><div class="gmail_extra">

thank you, Luigi Pirelli (<a href="mailto:luigi.pirelli@faunalia.it">luigi.pirelli@faunalia.it</a>)</div></div>