[Qgis-developer] index in self.legend.groupLayerRelationship - different behavior between QGIS 1.8 and master?

[Petros Apotsos]

On Fri, Oct 5, 2012 at 11:28 AM, Massimo <massimo.endrighi at geopartner.it>
wrote:
>
> Thus I propose another solution based on QDomDocument similar to the 
> one adopted into the QgsLegend::writeProject method.
> The returned document will contain only groups and layers names and 
> indexes, like the following example:
> <!DOCTYPE Group Layer Hierarchy>
> <Legend>
>  <Group Name="G0" Index="0">
>   <Layer GroupIndex="0" Id="L020120904162647883" Name="L0" Index="0"/>
>   <Group Name="G1" Index="1">
>    <Group Name="G2" Index="2">
>     <Layer GroupIndex="2" Id="L120120904162647883" Name="L1" Index="1"/>
>     <Layer GroupIndex="2" Id="L220120904162647382" Name="L2" Index="2"/>
>     <Layer GroupIndex="2" Id="L320120904162644097" Name="L3" Index="3"/>
>    </Group>
>    <Group Name="G3" Index="3">
>     <Layer GroupIndex="3" Id="L40120904162648624" Name="L4" Index="4"/>
>    </Group>
>    <Group Name="G4" Index="4">
>     <Layer GroupIndex="4" Id="L520120904162649445" Name="L5" Index="5"/>
>    </Group>
>   </Group>
>  </Group>
> </Legend>

DOM approach would be fine for read-only access... for operations that
change the hierarchy (e.g. create group G5 within group G3, or move layer L0
to group G4) it would be good to have classes that represent the legend
items, something like this:

class LegendInterface
{
  LegendItem* root(); // return top-level group (virtual) }

class LegendItem
{
  ItemType type(); // either group or layer
  LegendItem* parent();
  QList<LegendItem*> children();
  int indexInParent();

  QString name();
  bool isExpanded();
  // + operations: rename, expand/collapse }

class LegendGroup : LegendItem
{
  bool isVisible();
  // + operations: add child group, remove child group, show/hide ...
}

class LegendLayer : LegendItem
{
  QgsMapLayer* layer();
  bool isVisible();
  // + operations: move to different group, show/hide, refresh symbology
items ...
}

Like this we could get rid of much of the awkwardness of legend interface.
What do you think?

Martin

Dear List,
I think this is one (of the many) cases where modeling and documentation of
the application classes (Current and Desirable state) could really help.
AFAIK while it is totally possible to use UML to model the QGIS classes and
procedures (Python and C++ are OO, such a work has not been done and when
issues like this one arise, it is inconvenient to:
	1) Evaluate the current status quo.
	2) Share this knowledge with other community members
	3) Cooperate with other developers to reach to the desired results.
Please, correct me if I am wrong, as I would really like to see UML
documentation of QGIS.
I myself have started such a work, but it progresses really slow, due to
financial and temporal restrictions. In that framework, I will try to model
the current Legend Items and use this thread replies (and my own knowledge)
to model a new proposal.
Martin's Notation is really useful towards that goal, but not as easily
conveyable as a UML model.

Awaiting for your opinions & answers.

Petros Apotsos

Rural & Surveying Engineer
Technical Chamber of Greece Registry Number 96798
Τ: 2310 220345
F: 2310 220346
Ermou 18A, Postal Code 54624
Thessaloniki, GREECE
 

__________ Information from ESET Smart Security, version of virus signature
database 7557 (20121008) __________

The message was checked by ESET Smart Security.

http://www.eset.com