[Qgis-developer] QgsLegendInterface binding updates, or QgsLegend overhaul?
kelly.thomas at hotmail.com.au
Thu Nov 29 17:49:46 PST 2012
> Date: Wed, 28 Nov 2012 13:11:50 -0700
> From: larrys at dakotacarto.com
> To: qgis-developer at lists.osgeo.org
> Subject: [Qgis-developer] QgsLegendInterface binding updates, or QgsLegend overhaul?
> I added to QgsLegendInterface today  and noticed how lacking the
> Python binding is when working with the legend, compared to the number
> of methods that could be exposed from QgsLegend. Looks like
> QgsLegendInterface really hasn't been updated since QGIS 1.5.
> Users/plugin devs have asked for better means of working with the
> legend, so my questions are:
> * Should there be an effort to bring many of the reasonable-to-expose
> methods from QgsLegend to QgsLegendInterface for 2.0 release?
> * OR, should QgsLegend be overhauled first (as there has been talk about)?
>  https://github.com/qgis/Quantum-GIS/commit/8260eab94ba52ecd9faea59632c61070c2aea70c
> , http://gis.stackexchange.com/questions/36937
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
I'm new to this and have missed the talk of a QgsLegend overhaul so I have no knowledge ofthe scope/reasons of the proposed changes. To provide further context I am developing a python plugin for use in a corporate environment where I can only target stable releases (1.8/2.0).
Generally providing access to an appropriate API will reduce the need for hackish code.
The change you have made will negate the current need to query the QTreeView to determineif the active layer is the only selected layer.
I would also find value in gaining access to groupSelectedLayers.
In the long term I also feel that control of sub-groups is essential (part of the overhaul?).
In summary I support exposing further legend controls before 2.0
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Qgis-developer