Legend refactoring - part II - ready for merge

[Martin Dobias]

Hi all

In recent weeks I have been busy with the second part of legend
refactoring. The main goals were:
- clean up the mess with legend - there are three different ways of
legend presentation/rendering: 1. in legend widget (now layer tree
view), 2. composer legend, 3. WMS legend
- make legend rendering independent from composer - so it can be used
elsewhere - in WMS or in GUI
- allow different strategies how legend for a layer is created - until
now the legend generation was hardcoded - this should allow things
like data-defined legend, labeling / diagrams in legend
- allow new types of legend items - for greater flexibility of item
appearance - e.g. show a gradient color ramp for raster layer

The code is in my repository:
https://github.com/wonder-sk/QGIS/compare/legend-refactoring-part2

To introduce the important new classes:
- QgsLegendRenderer - takes care of rendering of the legend - similar
to how QgsMapRenderer handles rendering of map
- QgsLegendSettings - contains user configuration of the legend
(fonts, colors, sizes, spacing) - similar to QgsMapSettings for map
- QgsMapLayerLegend - base class for legend implementations. For a
layer an implementation should return a list of legend nodes
- QgsLayerTreeModelLegendNode - base class for legend node
implementation. Provides data(), flags() methods used in the layer
tree model and provides draw() method for rendering of legend in
composer/WMS

The QgsMapLayerLegend and QgsLayerTreeModelLegendNode classes are used
by QgsLayerTreeModel to generate and display legend in a tree.
QgsLegendRenderer makes use of QgsLayerTreeModel and allows the legend
nodes do their legend rendering.

An example of custom legend node:
- screenshot: Loading Image...
- code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401

An example of custom dock widget using legend renderer:
- screenshot: Loading Image...
- code: https://gist.github.com/wonder-sk/211b7130b58e50d78e6d
(in the screenshot above you can also see legend node icon embedded in
layer node)

There are not many changes visible to the user - the changes are
mainly visible for developers. From the few user-visible changes:
- in layer tree view - if a layer has just one legend item, it will be
shown on the left side of the layer name instead of occupying another
line. This is what already happens in composer.
- in composer legend item settings - 1) there is tree view with just
one column, label style is set in popup menu, 2) when auto-update is
on, the tree view is synchronized with project's layer tree and it is
read-only. When auto-update is off, it is possible to manipulate the
source legend tree

Regarding backward compatibility, there are two things worth mentioning:
- QgsComposerLegend::model() will return QgsLegendModel which is not
in use anymore. There is QgsComposerLegend::modelV2() as a
replacement. The way how the models work is significantly different
and I don't see a way of fixing that without a complex and fragile
synchronization logic. Anyway, according to Nathan's plugin analyser
tool there are no plugins using composer's legend model
- reading of older projects with composer legend ignores the
customization (e.g. renamed items, reordered items, removed items). If
time allows, I will try to address this before the release

So... please have a look if you are interested and enjoy the endless
possibilities of new legends :-)
If there are no objections I will merge it during the next week.

Regards
Martin

[Marco Hugentobler]

Hi Martin

Post by Martin Dobias
If there are no objections I will merge it during the next week.

You should give people at least a full week to look at the new code.

Regards,
Marco

Post by Martin Dobias
Hi all
In recent weeks I have been busy with the second part of legend
- clean up the mess with legend - there are three different ways of
legend presentation/rendering: 1. in legend widget (now layer tree
view), 2. composer legend, 3. WMS legend
- make legend rendering independent from composer - so it can be used
elsewhere - in WMS or in GUI
- allow different strategies how legend for a layer is created - until
now the legend generation was hardcoded - this should allow things
like data-defined legend, labeling / diagrams in legend
- allow new types of legend items - for greater flexibility of item
appearance - e.g. show a gradient color ramp for raster layer
https://github.com/wonder-sk/QGIS/compare/legend-refactoring-part2
- QgsLegendRenderer - takes care of rendering of the legend - similar
to how QgsMapRenderer handles rendering of map
- QgsLegendSettings - contains user configuration of the legend
(fonts, colors, sizes, spacing) - similar to QgsMapSettings for map
- QgsMapLayerLegend - base class for legend implementations. For a
layer an implementation should return a list of legend nodes
- QgsLayerTreeModelLegendNode - base class for legend node
implementation. Provides data(), flags() methods used in the layer
tree model and provides draw() method for rendering of legend in
composer/WMS
The QgsMapLayerLegend and QgsLayerTreeModelLegendNode classes are used
by QgsLayerTreeModel to generate and display legend in a tree.
QgsLegendRenderer makes use of QgsLayerTreeModel and allows the legend
nodes do their legend rendering.
- screenshot: http://i.imgur.com/GtvTlQ7.png
- code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401
- screenshot: http://i.imgur.com/EAvE96u.png
- code: https://gist.github.com/wonder-sk/211b7130b58e50d78e6d
(in the screenshot above you can also see legend node icon embedded in
layer node)
There are not many changes visible to the user - the changes are
- in layer tree view - if a layer has just one legend item, it will be
shown on the left side of the layer name instead of occupying another
line. This is what already happens in composer.
- in composer legend item settings - 1) there is tree view with just
one column, label style is set in popup menu, 2) when auto-update is
on, the tree view is synchronized with project's layer tree and it is
read-only. When auto-update is off, it is possible to manipulate the
source legend tree
- QgsComposerLegend::model() will return QgsLegendModel which is not
in use anymore. There is QgsComposerLegend::modelV2() as a
replacement. The way how the models work is significantly different
and I don't see a way of fixing that without a complex and fragile
synchronization logic. Anyway, according to Nathan's plugin analyser
tool there are no plugins using composer's legend model
- reading of older projects with composer legend ignores the
customization (e.g. renamed items, reordered items, removed items). If
time allows, I will try to address this before the release
So... please have a look if you are interested and enjoy the endless
possibilities of new legends :-)
If there are no objections I will merge it during the next week.
Regards
Martin
_______________________________________________
Qgis-developer mailing list
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Tim Sutton]

Hi Martin

Post by Martin Dobias
Hi all
In recent weeks I have been busy with the second part of legend
refactoring. The main goals were: - clean up the mess with legend -
there are three different ways of legend presentation/rendering: 1.
in legend widget (now layer tree view), 2. composer legend, 3. WMS
legend - make legend rendering independent from composer - so it
can be used elsewhere - in WMS or in GUI - allow different
strategies how legend for a layer is created - until now the legend
generation was hardcoded - this should allow things like
data-defined legend, labeling / diagrams in legend - allow new
types of legend items - for greater flexibility of item appearance
- e.g. show a gradient color ramp for raster layer
https://github.com/wonder-sk/QGIS/compare/legend-refactoring-part2
To introduce the important new classes: - QgsLegendRenderer - takes
care of rendering of the legend - similar to how QgsMapRenderer
handles rendering of map - QgsLegendSettings - contains user
configuration of the legend (fonts, colors, sizes, spacing) -
similar to QgsMapSettings for map - QgsMapLayerLegend - base class
for legend implementations. For a layer an implementation should
return a list of legend nodes - QgsLayerTreeModelLegendNode - base
class for legend node implementation. Provides data(), flags()
methods used in the layer tree model and provides draw() method for
rendering of legend in composer/WMS
The QgsMapLayerLegend and QgsLayerTreeModelLegendNode classes are
used by QgsLayerTreeModel to generate and display legend in a
tree. QgsLegendRenderer makes use of QgsLayerTreeModel and allows
the legend nodes do their legend rendering.
https://gist.github.com/wonder-sk/c5d925833bcd54b9e401
An example of custom dock widget using legend renderer: -
https://gist.github.com/wonder-sk/211b7130b58e50d78e6d (in the
screenshot above you can also see legend node icon embedded in
layer node)
There are not many changes visible to the user - the changes are
mainly visible for developers. From the few user-visible changes: -
in layer tree view - if a layer has just one legend item, it will
be shown on the left side of the layer name instead of occupying
another line. This is what already happens in composer. - in
composer legend item settings - 1) there is tree view with just one
column, label style is set in popup menu, 2) when auto-update is
on, the tree view is synchronized with project's layer tree and it
is read-only. When auto-update is off, it is possible to manipulate
the source legend tree
Regarding backward compatibility, there are two things worth
mentioning: - QgsComposerLegend::model() will return QgsLegendModel
which is not in use anymore. There is QgsComposerLegend::modelV2()
as a replacement. The way how the models work is significantly
different and I don't see a way of fixing that without a complex
and fragile synchronization logic. Anyway, according to Nathan's
plugin analyser tool there are no plugins using composer's legend
model - reading of older projects with composer legend ignores the
customization (e.g. renamed items, reordered items, removed items).
If time allows, I will try to address this before the release
So... please have a look if you are interested and enjoy the
endless possibilities of new legends :-) If there are no objections
I will merge it during the next week.

Ah wow - I've been playing with it here and it is so much nicer from
the UI point of view. Two things I picked up though.

* I don't know how to reproduce it exactly but it seems that when I
change the text for a layer name in general properties it updates the
legend fine but after using QGIS a little more I notice that the layer
name reverts to its previous state. I will post more details if I
figure out how to replicate this.

* Do you have any strategy for dealing with symbols larger than the
thumbnail in the legend? e.g. if you set the size of a circle to 8 it
basically draws a square. This is not a regression as the old legend
implementation suffered the same thing, but I was hoping a new
implementation could offer a fix for this. I know there are limits to
what we can do in the space of the legend but perhaps having some
simple system whereby symbol previews are proportionally scaled such
that the largest icon will always fit into the space provided and the
smaller ones are relatively reduced in scale? Perhaps someone else has
some creative ideas on how to improve their visual representation in
the legend?

Great stuff as always Martin!

Regards

Tim

Post by Martin Dobias
Regards Martin _______________________________________________
http://lists.osgeo.org/mailman/listinfo/qgis-developer

- --
- ------------------------------------------------------

Tim Sutton
Visit http://kartoza.com to find out about open source:
* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee
- ------------------------------------------------------
Kartoza is a merger between Linfiniti and Afrispatial

[Tim Sutton]

Hi

Post by Marco Hugentobler
Hi Martin

Post by Martin Dobias
Hi all
In recent weeks I have been busy with the second part of legend
refactoring. The main goals were: - clean up the mess with legend
- there are three different ways of legend
presentation/rendering: 1. in legend widget (now layer tree
view), 2. composer legend, 3. WMS legend - make legend rendering
independent from composer - so it can be used elsewhere - in WMS
or in GUI - allow different strategies how legend for a layer is
created - until now the legend generation was hardcoded - this
should allow things like data-defined legend, labeling / diagrams
in legend - allow new types of legend items - for greater
flexibility of item appearance - e.g. show a gradient color ramp
for raster layer
https://github.com/wonder-sk/QGIS/compare/legend-refactoring-part2
To introduce the important new classes: - QgsLegendRenderer -
takes care of rendering of the legend - similar to how
QgsMapRenderer handles rendering of map - QgsLegendSettings -
contains user configuration of the legend (fonts, colors, sizes,
spacing) - similar to QgsMapSettings for map - QgsMapLayerLegend
- base class for legend implementations. For a layer an
implementation should return a list of legend nodes -
QgsLayerTreeModelLegendNode - base class for legend node
implementation. Provides data(), flags() methods used in the
layer tree model and provides draw() method for rendering of
legend in composer/WMS
The QgsMapLayerLegend and QgsLayerTreeModelLegendNode classes
are used by QgsLayerTreeModel to generate and display legend in
a tree. QgsLegendRenderer makes use of QgsLayerTreeModel and
allows the legend nodes do their legend rendering.
https://gist.github.com/wonder-sk/c5d925833bcd54b9e401
An example of custom dock widget using legend renderer: -
https://gist.github.com/wonder-sk/211b7130b58e50d78e6d (in the
screenshot above you can also see legend node icon embedded in
layer node)
There are not many changes visible to the user - the changes are
mainly visible for developers. From the few user-visible
changes: - in layer tree view - if a layer has just one legend
item, it will be shown on the left side of the layer name instead
of occupying another line. This is what already happens in
composer. - in composer legend item settings - 1) there is tree
view with just one column, label style is set in popup menu, 2)
when auto-update is on, the tree view is synchronized with
project's layer tree and it is read-only. When auto-update is
off, it is possible to manipulate the source legend tree
Regarding backward compatibility, there are two things worth
mentioning: - QgsComposerLegend::model() will return
QgsLegendModel which is not in use anymore. There is
QgsComposerLegend::modelV2() as a replacement. The way how the
models work is significantly different and I don't see a way of
fixing that without a complex and fragile synchronization logic.
Anyway, according to Nathan's plugin analyser tool there are no
plugins using composer's legend model - reading of older projects
with composer legend ignores the customization (e.g. renamed
items, reordered items, removed items). If time allows, I will
try to address this before the release
So... please have a look if you are interested and enjoy the
endless possibilities of new legends :-) If there are no
objections I will merge it during the next week.

Ah wow - I've been playing with it here and it is so much nicer
from the UI point of view. Two things I picked up though.
* I don't know how to reproduce it exactly but it seems that when
I change the text for a layer name in general properties it updates
the legend fine but after using QGIS a little more I notice that
the layer name reverts to its previous state. I will post more
details if I figure out how to replicate this.

Ok on a little further investigation it seems this is an issue with
renaming gpx layers - I suspect the driver is at fault here since it
does it in QGIS 2.4 too.

Regards

Tim

Post by Marco Hugentobler
* Do you have any strategy for dealing with symbols larger than
the thumbnail in the legend? e.g. if you set the size of a circle
to 8 it basically draws a square. This is not a regression as the
old legend implementation suffered the same thing, but I was hoping
a new implementation could offer a fix for this. I know there are
limits to what we can do in the space of the legend but perhaps
having some simple system whereby symbol previews are
proportionally scaled such that the largest icon will always fit
into the space provided and the smaller ones are relatively reduced
in scale? Perhaps someone else has some creative ideas on how to
improve their visual representation in the legend?
Great stuff as always Martin!
Regards
Tim

Post by Martin Dobias
Regards Martin _______________________________________________
http://lists.osgeo.org/mailman/listinfo/qgis-developer

- --
- ------------------------------------------------------

Tim Sutton
Visit http://kartoza.com to find out about open source:
* Desktop GIS programming services
* Geospatial web development
* GIS Training
* Consulting Services
Skype: timlinux Irc: timlinux on #qgis at freenode.net
Tim is a member of the QGIS Project Steering Committee
- ------------------------------------------------------
Kartoza is a merger between Linfiniti and Afrispatial

[Leyan]

Post by Tim Sutton
* Do you have any strategy for dealing with symbols larger than the
thumbnail in the legend? e.g. if you set the size of a circle to 8 it
basically draws a square. This is not a regression as the old legend
implementation suffered the same thing, but I was hoping a new
implementation could offer a fix for this. I know there are limits to
what we can do in the space of the legend but perhaps having some
simple system whereby symbol previews are proportionally scaled such
that the largest icon will always fit into the space provided and the
smaller ones are relatively reduced in scale? Perhaps someone else has
some creative ideas on how to improve their visual representation in
the legend? Great stuff as always Martin! Regards Tim

I agree it is a major issue of the legend currently. I think the best
would be to have it scaled to get the largest symbol to fit in the
square and the others proportional to it, but marking that it has been
scaled (for example with a frame) and show the actual size (in a small
popup?) when hovering on or clicking the symbol.

Regards,

Leyan

[Martin Dobias]

Hi Tim!

Post by Tim Sutton
Ah wow - I've been playing with it here and it is so much nicer from
the UI point of view. Two things I picked up though.
* I don't know how to reproduce it exactly but it seems that when I
change the text for a layer name in general properties it updates the
legend fine but after using QGIS a little more I notice that the layer
name reverts to its previous state. I will post more details if I
figure out how to replicate this.

If you will find the pattern how to reproduce it, feel free to report
an issue - glad to hear the bug is not caused by the refactoring
though :-) (according to your latter mail)

Post by Tim Sutton
* Do you have any strategy for dealing with symbols larger than the
thumbnail in the legend? e.g. if you set the size of a circle to 8 it
basically draws a square. This is not a regression as the old legend
implementation suffered the same thing, but I was hoping a new
implementation could offer a fix for this. I know there are limits to
what we can do in the space of the legend but perhaps having some
simple system whereby symbol previews are proportionally scaled such
that the largest icon will always fit into the space provided and the
smaller ones are relatively reduced in scale? Perhaps someone else has
some creative ideas on how to improve their visual representation in
the legend?

Yes this is still an issue. The legend icon in the layer tree has more
problems than just fixed maximum symbol size. It also ignores the fact
that some symbols may have size specified in map units and assumes
that one map unit == one millimeter. Moreover such legend entries
should be probably updated every time that map scale changes (which
may have a negative performance impact) or at least once upon a time.
But thanks to the refactoring it should be easier to address the
issue. In map composer legend, rendering of the legend is now done
correctly and the code for rendering of symbol icons for both layer
tree and composer (and WMS!) is now just in one class
(QgsSymbolV2LegendNode).

For a strategy with big symbols I would suggest (for a future implementation):
- have a default symbol icon size (as of now)
- allow symbol icons to become bigger up to some maximum icon size
- symbols bigger than maximum size would be scaled with a small note
underneath how much they are scaled (e.g. "1:5")

Cheers
Martin

[Luigi Pirelli]

Hi martin,

I'll try to have a check of your modification on wms legend next days (or week)

Post by Martin Dobias
Hi all
In recent weeks I have been busy with the second part of legend
- clean up the mess with legend - there are three different ways of
legend presentation/rendering: 1. in legend widget (now layer tree
view), 2. composer legend, 3. WMS legend
- make legend rendering independent from composer - so it can be used
elsewhere - in WMS or in GUI
- allow different strategies how legend for a layer is created - until
now the legend generation was hardcoded - this should allow things
like data-defined legend, labeling / diagrams in legend
- allow new types of legend items - for greater flexibility of item
appearance - e.g. show a gradient color ramp for raster layer
https://github.com/wonder-sk/QGIS/compare/legend-refactoring-part2
- QgsLegendRenderer - takes care of rendering of the legend - similar
to how QgsMapRenderer handles rendering of map
- QgsLegendSettings - contains user configuration of the legend
(fonts, colors, sizes, spacing) - similar to QgsMapSettings for map
- QgsMapLayerLegend - base class for legend implementations. For a
layer an implementation should return a list of legend nodes
- QgsLayerTreeModelLegendNode - base class for legend node
implementation. Provides data(), flags() methods used in the layer
tree model and provides draw() method for rendering of legend in
composer/WMS
The QgsMapLayerLegend and QgsLayerTreeModelLegendNode classes are used
by QgsLayerTreeModel to generate and display legend in a tree.
QgsLegendRenderer makes use of QgsLayerTreeModel and allows the legend
nodes do their legend rendering.
- screenshot: http://i.imgur.com/GtvTlQ7.png
- code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401
- screenshot: http://i.imgur.com/EAvE96u.png
- code: https://gist.github.com/wonder-sk/211b7130b58e50d78e6d
(in the screenshot above you can also see legend node icon embedded in
layer node)
There are not many changes visible to the user - the changes are
- in layer tree view - if a layer has just one legend item, it will be
shown on the left side of the layer name instead of occupying another
line. This is what already happens in composer.
- in composer legend item settings - 1) there is tree view with just
one column, label style is set in popup menu, 2) when auto-update is
on, the tree view is synchronized with project's layer tree and it is
read-only. When auto-update is off, it is possible to manipulate the
source legend tree
- QgsComposerLegend::model() will return QgsLegendModel which is not
in use anymore. There is QgsComposerLegend::modelV2() as a
replacement. The way how the models work is significantly different
and I don't see a way of fixing that without a complex and fragile
synchronization logic. Anyway, according to Nathan's plugin analyser
tool there are no plugins using composer's legend model
- reading of older projects with composer legend ignores the
customization (e.g. renamed items, reordered items, removed items). If
time allows, I will try to address this before the release
So... please have a look if you are interested and enjoy the endless
possibilities of new legends :-)
If there are no objections I will merge it during the next week.
Regards
Martin
_______________________________________________
Qgis-developer mailing list
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Denis Rouzaud]

Hi Martin,

This sounds quite exciting!
Thanks a lot for this large refactoring!

I can't tell much for the code part. However, I have a few remarks from
testing:

* Removing a symbol in the rule based symbology that was used as a group
without any symbol does not removie it from the legend.
e.g.
Layer
|
---- scale group without symbol
|
------- symbol xxx

If I move "symbol xxx" to the top level and delete the scale group, it's
not removed from the legend.


* In the case of a rule based renderer has a single top level rule, I
would suggest that this top rule is not shown as a symbol but directly
at the layer level (similarly to a single symbol layer).
An example of such config:


and in the legend:



I would propose that "réseau" symbol label is hidden, and its symbol is
shown on the layer level directly.


* Also would it be too complicated to reproduce the rule-based hierarchy
in the legend as a tree? Is it out of scope?


Thanks again for this.
I am looking forward to further testing in master :)

Best wishes,

Denis

Post by Martin Dobias
Hi all
In recent weeks I have been busy with the second part of legend
- clean up the mess with legend - there are three different ways of
legend presentation/rendering: 1. in legend widget (now layer tree
view), 2. composer legend, 3. WMS legend
- make legend rendering independent from composer - so it can be used
elsewhere - in WMS or in GUI
- allow different strategies how legend for a layer is created - until
now the legend generation was hardcoded - this should allow things
like data-defined legend, labeling / diagrams in legend
- allow new types of legend items - for greater flexibility of item
appearance - e.g. show a gradient color ramp for raster layer
https://github.com/wonder-sk/QGIS/compare/legend-refactoring-part2
- QgsLegendRenderer - takes care of rendering of the legend - similar
to how QgsMapRenderer handles rendering of map
- QgsLegendSettings - contains user configuration of the legend
(fonts, colors, sizes, spacing) - similar to QgsMapSettings for map
- QgsMapLayerLegend - base class for legend implementations. For a
layer an implementation should return a list of legend nodes
- QgsLayerTreeModelLegendNode - base class for legend node
implementation. Provides data(), flags() methods used in the layer
tree model and provides draw() method for rendering of legend in
composer/WMS
The QgsMapLayerLegend and QgsLayerTreeModelLegendNode classes are used
by QgsLayerTreeModel to generate and display legend in a tree.
QgsLegendRenderer makes use of QgsLayerTreeModel and allows the legend
nodes do their legend rendering.
- screenshot: http://i.imgur.com/GtvTlQ7.png
- code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401
- screenshot: http://i.imgur.com/EAvE96u.png
- code: https://gist.github.com/wonder-sk/211b7130b58e50d78e6d
(in the screenshot above you can also see legend node icon embedded in
layer node)
There are not many changes visible to the user - the changes are
- in layer tree view - if a layer has just one legend item, it will be
shown on the left side of the layer name instead of occupying another
line. This is what already happens in composer.
- in composer legend item settings - 1) there is tree view with just
one column, label style is set in popup menu, 2) when auto-update is
on, the tree view is synchronized with project's layer tree and it is
read-only. When auto-update is off, it is possible to manipulate the
source legend tree
- QgsComposerLegend::model() will return QgsLegendModel which is not
in use anymore. There is QgsComposerLegend::modelV2() as a
replacement. The way how the models work is significantly different
and I don't see a way of fixing that without a complex and fragile
synchronization logic. Anyway, according to Nathan's plugin analyser
tool there are no plugins using composer's legend model
- reading of older projects with composer legend ignores the
customization (e.g. renamed items, reordered items, removed items). If
time allows, I will try to address this before the release
So... please have a look if you are interested and enjoy the endless
possibilities of new legends :-)
If there are no objections I will merge it during the next week.
Regards
Martin
_______________________________________________
Qgis-developer mailing list
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Martin Dobias]

Hi Denis

thanks for testing!

Post by Denis Rouzaud
* In the case of a rule based renderer has a single top level rule, I
would suggest that this top rule is not shown as a symbol but directly at
the layer level (similarly to a single symbol layer).

I would propose that "réseau" symbol label is hidden, and its symbol is
shown on the layer level directly.

That would be possible, it would require some adjustments though. Currently
symbol's icon is shown at the layer level only if these two conditions are
met:
- there is only one legend node for layer
- the legend node has property "embedded in parent" set to true


* Also would it be too complicated to reproduce the rule-based hierarchy in

Post by Denis Rouzaud
the legend as a tree? Is it out of scope?

The legend nodes are intentionally kept in a list. Another tree structure
just for legend nodes would make things much more complex and the
rule-based renderer is probably the only case where it would have some
added value. In the future, if we support item delegates for legend nodes,
we could maybe achieve some pseudo-tree behaviour for rule-based renderer.
But currently that's out of scope...

Cheers
Martin

[Anita Graser]

Hi Martin,

Before the refactoring, a newly added layer was automatically the active
layer. This is not the case with the new legend. Was this a conscious
decision? From a user standpoint, the previous behavior made more sense:
Now, after adding the layer, I have to click it in the layer list before I
can open the attribute table or do anything else with e.g. the toolbar
tools.

Should I open a ticket?

Best wishes,
Anita

[Paolo Cavallini]

Post by Anita Graser
Before the refactoring, a newly added layer was automatically the
active layer. This is not the case with the new legend. Was this a
conscious decision? From a user standpoint, the previous behavior

Agreed, I also find this new behaviour annoying.
Thanks.

- --
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html

[Luigi Pirelli]

+1

Post by Denis Rouzaud
Hi Martin,
Before the refactoring, a newly added layer was automatically the active
layer. This is not the case with the new legend. Was this a conscious
Now, after adding the layer, I have to click it in the layer list before I
can open the attribute table or do anything else with e.g. the toolbar
tools.
Should I open a ticket?
Best wishes,
Anita
_______________________________________________
Qgis-developer mailing list
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Martin Dobias]

Hi Anita

I think setting of active layer to the newly added layer was
previously (<2.4) a side effect of something else - and the removal
was not completely intentional. There is no problem to add that
behavior back... feel free to open a ticket.

Cheers
Martin

Post by Denis Rouzaud
Hi Martin,
Before the refactoring, a newly added layer was automatically the active
layer. This is not the case with the new legend. Was this a conscious
Now, after adding the layer, I have to click it in the layer list before I
can open the attribute table or do anything else with e.g. the toolbar
tools.
Should I open a ticket?
Best wishes,
Anita

[Anita Graser]

Post by Martin Dobias
Hi Anita
I think setting of active layer to the newly added layer was
previously (<2.4) a side effect of something else - and the removal
was not completely intentional. There is no problem to add that
behavior back... feel free to open a ticket.

Done: http://hub.qgis.org/issues/11369


Thanks and best wishes,
Anita

[Marco Hugentobler]

Hi Martin

Thanks for your efforts to unify the legends. Few comments from my side:

- API break: is there a list of breaks inside the 2.x series? I recently
came accross one in the provider API, and it would be good to provide
some guidance for people porting code to newer versions. Regarding 'not
used according to plugin analysis tool': most plugins are probably not
in the plugin repo.

- For the legend graphics options layertitlespace and layerfontcolor, it
says 'TODO'.

- qgswmsserver.cpp:671 : it seems a bit strange to iterate over all
nodes to set the property. Can this be done inside some legend class
(maybe legend renderer)?

Regards,
Marco

Post by Martin Dobias
Hi all
In recent weeks I have been busy with the second part of legend
- clean up the mess with legend - there are three different ways of
legend presentation/rendering: 1. in legend widget (now layer tree
view), 2. composer legend, 3. WMS legend
- make legend rendering independent from composer - so it can be used
elsewhere - in WMS or in GUI
- allow different strategies how legend for a layer is created - until
now the legend generation was hardcoded - this should allow things
like data-defined legend, labeling / diagrams in legend
- allow new types of legend items - for greater flexibility of item
appearance - e.g. show a gradient color ramp for raster layer
https://github.com/wonder-sk/QGIS/compare/legend-refactoring-part2
- QgsLegendRenderer - takes care of rendering of the legend - similar
to how QgsMapRenderer handles rendering of map
- QgsLegendSettings - contains user configuration of the legend
(fonts, colors, sizes, spacing) - similar to QgsMapSettings for map
- QgsMapLayerLegend - base class for legend implementations. For a
layer an implementation should return a list of legend nodes
- QgsLayerTreeModelLegendNode - base class for legend node
implementation. Provides data(), flags() methods used in the layer
tree model and provides draw() method for rendering of legend in
composer/WMS
The QgsMapLayerLegend and QgsLayerTreeModelLegendNode classes are used
by QgsLayerTreeModel to generate and display legend in a tree.
QgsLegendRenderer makes use of QgsLayerTreeModel and allows the legend
nodes do their legend rendering.
- screenshot: http://i.imgur.com/GtvTlQ7.png
- code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401
- screenshot: http://i.imgur.com/EAvE96u.png
- code: https://gist.github.com/wonder-sk/211b7130b58e50d78e6d
(in the screenshot above you can also see legend node icon embedded in
layer node)
There are not many changes visible to the user - the changes are
- in layer tree view - if a layer has just one legend item, it will be
shown on the left side of the layer name instead of occupying another
line. This is what already happens in composer.
- in composer legend item settings - 1) there is tree view with just
one column, label style is set in popup menu, 2) when auto-update is
on, the tree view is synchronized with project's layer tree and it is
read-only. When auto-update is off, it is possible to manipulate the
source legend tree
- QgsComposerLegend::model() will return QgsLegendModel which is not
in use anymore. There is QgsComposerLegend::modelV2() as a
replacement. The way how the models work is significantly different
and I don't see a way of fixing that without a complex and fragile
synchronization logic. Anyway, according to Nathan's plugin analyser
tool there are no plugins using composer's legend model
- reading of older projects with composer legend ignores the
customization (e.g. renamed items, reordered items, removed items). If
time allows, I will try to address this before the release
So... please have a look if you are interested and enjoy the endless
possibilities of new legends :-)
If there are no objections I will merge it during the next week.
Regards
Martin
_______________________________________________
Qgis-developer mailing list
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Martin Dobias]

Hi Marco

thanks for you comments.

On Tue, Aug 26, 2014 at 3:38 PM, Marco Hugentobler

Post by Marco Hugentobler
Hi Martin
- API break: is there a list of breaks inside the 2.x series? I recently
came accross one in the provider API, and it would be good to provide some
guidance for people porting code to newer versions. Regarding 'not used
according to plugin analysis tool': most plugins are probably not in the
plugin repo.

I am not aware of such list - but it is the right time to start one.
Do you have any preferences where to put it - doxygen page / wiki page
/ qgis-documentation repo / somewhere else?

Post by Marco Hugentobler
- For the legend graphics options layertitlespace and layerfontcolor, it
says 'TODO'.

Something to be addressed - these features are not supported out of
the box by QgsLegendRenderer. Btw. are these custom options documented
/ used anywhere?

Post by Marco Hugentobler
- qgswmsserver.cpp:671 : it seems a bit strange to iterate over all nodes to
set the property. Can this be done inside some legend class (maybe legend
renderer)?

This looks OK to me - I don't think we do not need another mechanism
to skip legend node labels... and other classes like legend renderer
are not supposed to alter the input model. Moreover this functionality
is special to WMS and it's just two lines of code, so I did not feel a
need to generalize it somehow.

Regards
Martin

[Paolo Cavallini]

Post by Martin Dobias
Do you have any preferences where to put it - doxygen page / wiki page
/ qgis-documentation repo / somewhere else?

-1 for wiki
thanks

[Marco Hugentobler]

Post by Paolo Cavallini
-1 for wiki
thanks

What place do you recommend then? Seems to me there is no developer
documentation in the qgis-documentation repo.

Post by Paolo Cavallini

Post by Martin Dobias
Do you have any preferences where to put it - doxygen page / wiki page
/ qgis-documentation repo / somewhere else?

-1 for wiki
thanks

[Jürgen E. Fischer]

Hi Marco,

Post by Marco Hugentobler

Post by Paolo Cavallini

Post by Martin Dobias
Do you have any preferences where to put it - doxygen page / wiki page
/ qgis-documentation repo / somewhere else?

-1 for wiki
thanks

What place do you recommend then? Seems to me there is no developer
documentation in the qgis-documentation repo.

That leaves doxygen. Why not document API breakages where the API is
documented? Sounds like the best fit ;)


Jürgen

[Marco Hugentobler]

Post by Jürgen E. Fischer
That leaves doxygen. Why not document API breakages where the API is
documented? Sounds like the best fit ;)

It's fine to put it into doxygen. Can it also be available as a
summarized list there (so not only as a comment at the method level)?

Post by Jürgen E. Fischer
Hi Marco,

Post by Marco Hugentobler

Post by Paolo Cavallini

Post by Martin Dobias
Do you have any preferences where to put it - doxygen page / wiki page
/ qgis-documentation repo / somewhere else?

-1 for wiki
thanks

What place do you recommend then? Seems to me there is no developer
documentation in the qgis-documentation repo.

That leaves doxygen. Why not document API breakages where the API is
documented? Sounds like the best fit ;)
Jürgen
_______________________________________________
Qgis-developer mailing list
http://lists.osgeo.org/mailman/listinfo/qgis-developer

[Martin Dobias]

Hi Marco

On Thu, Aug 28, 2014 at 2:33 PM, Marco Hugentobler

Post by Jürgen E. Fischer
That leaves doxygen. Why not document API breakages where the API is
documented? Sounds like the best fit ;)

It's fine to put it into doxygen. Can it also be available as a summarized
list there (so not only as a comment at the method level)?

I have started API break doxygen page:
https://github.com/qgis/QGIS/blob/master/doc/api_break.dox

It is also linked from the main documentation page.

Regards
Martin

[Nyall Dawson]

Post by Jürgen E. Fischer
That leaves doxygen. Why not document API breakages where the API is
documented? Sounds like the best fit ;)

That's fine, until those deprecated methods are removed. Then the api break
documentation will be removed as well...

Nyall

[Martin Dobias]

Hi Nyall

Post by Nyall Dawson

Post by Jürgen E. Fischer
That leaves doxygen. Why not document API breakages where the API is
documented? Sounds like the best fit ;)

That's fine, until those deprecated methods are removed. Then the api break
documentation will be removed as well...

The idea is to have an explicit list (a doxygen page) with the
incompatible changes - so nothing should get lost if stuff it removed.

Cheers
Martin

[Marco Hugentobler]

Post by Martin Dobias
Something to be addressed - these features are not supported out of
the box by QgsLegendRenderer. Btw. are these custom options documented
/ used anywhere?

The additional wms legend parameters are documented here:

http://hub.qgis.org/projects/quantum-gis/wiki/QGIS_Server_Tutorial#GetLegendGraphics

Regards,
Marco

Post by Martin Dobias
Hi Marco
thanks for you comments.
On Tue, Aug 26, 2014 at 3:38 PM, Marco Hugentobler

Post by Marco Hugentobler
Hi Martin
- API break: is there a list of breaks inside the 2.x series? I recently
came accross one in the provider API, and it would be good to provide some
guidance for people porting code to newer versions. Regarding 'not used
according to plugin analysis tool': most plugins are probably not in the
plugin repo.

I am not aware of such list - but it is the right time to start one.
Do you have any preferences where to put it - doxygen page / wiki page
/ qgis-documentation repo / somewhere else?

Post by Marco Hugentobler
- For the legend graphics options layertitlespace and layerfontcolor, it
says 'TODO'.

Something to be addressed - these features are not supported out of
the box by QgsLegendRenderer. Btw. are these custom options documented
/ used anywhere?

Post by Marco Hugentobler
- qgswmsserver.cpp:671 : it seems a bit strange to iterate over all nodes to
set the property. Can this be done inside some legend class (maybe legend
renderer)?

This looks OK to me - I don't think we do not need another mechanism
to skip legend node labels... and other classes like legend renderer
are not supposed to alter the input model. Moreover this functionality
is special to WMS and it's just two lines of code, so I did not feel a
need to generalize it somehow.
Regards
Martin