Re: [Qgis-developer] Legend refactoring - part II - ready for merge
Hi Marco On Thu, Aug 28, 2014 at 2:33 PM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
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 On 27.08.2014 05:40, Martin Dobias wrote: Hi Marco thanks for you comments. On Tue, Aug 26, 2014 at 3:38 PM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: 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. 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? - 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? - 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 -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
Hi Marco, On Thu, 28. Aug 2014 at 09:03:49 +0200, Marco Hugentobler wrote: On 27.08.2014 09:27, Paolo Cavallini wrote: Il 27/08/2014 05:40, Martin Dobias ha scritto: 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 -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13 Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS release manager (PSC) GermanyIRC: jef on FreeNode signature.asc Description: Digital signature ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
On 28/08/2014 5:29 pm, Jürgen E. j...@norbit.de wrote: 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
Hi Nyall On Thu, Aug 28, 2014 at 5:33 PM, Nyall Dawson nyall.daw...@gmail.com wrote: On 28/08/2014 5:29 pm, Jürgen E. j...@norbit.de wrote: 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
Il 27/08/2014 05:40, Martin Dobias ha scritto: Do you have any preferences where to put it - doxygen page / wiki page / qgis-documentation repo / somewhere else? -1 for wiki thanks -- Paolo Cavallini - www.faunalia.eu Corsi QGIS e PostGIS: http://www.faunalia.eu/training.html ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
Hi Tim! On Sun, Aug 24, 2014 at 2:51 PM, Tim Sutton t...@kartoza.com wrote: 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) * 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
Hi Denis thanks for testing! On Tue, Aug 26, 2014 at 12:32 PM, Denis Rouzaud denis.rouz...@gmail.com wrote: * 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. 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 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
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 On 22.08.2014 13:02, Martin Dobias wrote: 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: http://i.imgur.com/GtvTlQ7.png - code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401 An example of custom dock widget using legend renderer: - 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 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
Hi Marco thanks for you comments. On Tue, Aug 26, 2014 at 3:38 PM, Marco Hugentobler marco.hugentob...@sourcepole.ch wrote: 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. 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? - 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? - 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
Hi martin, I'll try to have a check of your modification on wms legend next days (or week) regards, Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com) On 22 August 2014 13:02, Martin Dobias wonder...@gmail.com wrote: 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: http://i.imgur.com/GtvTlQ7.png - code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401 An example of custom dock widget using legend renderer: - 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 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
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 On 22.08.2014 13:02, Martin Dobias wrote: 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: http://i.imgur.com/GtvTlQ7.png - code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401 An example of custom dock widget using legend renderer: - 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 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Martin On 22/08/2014 13:02, Martin Dobias wrote: 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: http://i.imgur.com/GtvTlQ7.png - code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401 An example of custom dock widget using legend renderer: - 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 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 Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi On 24/08/2014 09:51, Tim Sutton wrote: Hi Martin On 22/08/2014 13:02, Martin Dobias wrote: 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: http://i.imgur.com/GtvTlQ7.png - code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401 An example of custom dock widget using legend renderer: - 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 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 * 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
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
On 08/24/2014 03:51 PM, Tim Sutton wrote: * 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Legend refactoring - part II - ready for merge
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: http://i.imgur.com/GtvTlQ7.png - code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401 An example of custom dock widget using legend renderer: - 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 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Legend refactoring - part II - ready for merge
Hi Martin 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 On 22.08.2014 13:02, Martin Dobias wrote: 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: http://i.imgur.com/GtvTlQ7.png - code: https://gist.github.com/wonder-sk/c5d925833bcd54b9e401 An example of custom dock widget using legend renderer: - 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 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
