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] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)
Hi Nyall Having another process to nominate QEP voters sounds too complicated to me. not everyone on the psc is a developer or has c++ coding experience There is a mix of coders and non-coders in the PSC on purpose. Developers sometimes have a narrow point of view, so it is good that also non-developers have a say. In the discussion part of the QEP, the consequences for users can be mentioned. I don't consider that a problem, even for very technical subjects (and even those usually have somehow an influence on the users of a software). I'm putting RFC/QEP on the agenda to discuss at the next PSC meeting (http://hub.qgis.org/wiki/quantum-gis/PSC_Meeting_5_September_2014). Regards, Marco On 23.08.2014 03:31, Nyall Dawson wrote: On 23/08/2014 3:33 am, Even Rouault even.roua...@spatialys.com mailto:even.roua...@spatialys.com wrote: Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit : - Who can vote? PSC only (GDAL) / committers With GIT, 'committers' can be anyone. You probably meant folks who have push rights in official repo ? If you give them voting rights, and potentially veto right (not sure how the rules of the voting system of QGIS are), then they are defacto PSC members, since they can steer the direction of the project. Not saying this is bad. Just a consequence. I'd say neither psc nor commit rights are a good fit. While I agree that the psc should definitely have a say, not everyone on the psc is a developer or has c++ coding experience. Similarly, we have people who have commit rights who are neither developers nor psc members. Since a big part of the qep would be commenting on proposed technical architecture, I think its fairly important that developers have a good say in the process. But conversely if the qep process determines the direction of QGIS, then non devs on the psc should also have a say. So, I'd say we need a new group for voters. We could have a process like: - a candidate is nominated seconded (possibly by psc members only?) - the candidate gives a short reasoning on why they'd like to be part of the group and what skills they have - after receiving a set number of votes the candidate is accepted into the group. (Again, possibly only the psc could vote on candidates?). Nyall ___ 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] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)
On Sun, Aug 24, 2014 at 7:44 PM, Nyall Dawson nyall.daw...@gmail.com wrote: OK, fair enough. But would non-psc members be able to comment on proposals? Everyone should have the right to comment. Just some people will have more weight then others. - Nathan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)
On 24.08.2014 11:46, Nathan Woodrow wrote: On Sun, Aug 24, 2014 at 7:44 PM, Nyall Dawson nyall.daw...@gmail.com mailto:nyall.daw...@gmail.com wrote: OK, fair enough. But would non-psc members be able to comment on proposals? Everyone should have the right to comment. Just some people will have more weight then others. That's also my opinion. Everyone can discuss, not everyone can vote (and my expectation is that controversial RFC/QEP will be very very rare). Regards, Marco -- 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
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
Re: [Qgis-developer] visual changelog incorporation in qgis.org
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi On 19/08/2014 18:35, Anita Graser wrote: Thanks Richard, It's great to have the changelog on the main website now. Let's see how we can link it prominently. Best wishes Anita On Aug 19, 2014 6:00 PM, Richard Duivenvoorde rdmaili...@duif.net mailto:rdmaili...@duif.net wrote: (sorry for cross posting) We finished the incorporation the outputs of http://changelog.linfiniti.com/qgis/version/2.4.0/ into the web site itself: http://qgis.org/en/site/forusers/visualchangelog240/QGIS-2.4.0.html http://qgis.org/en/site/forusers/visualchangelog220/QGIS-2.2.0.html http://qgis.org/en/site/forusers/visualchangelog200/QGIS-2.0.0.html Before we retrieved the changelog data as a atom feed (without images), peeled it with JQuery and injected it in the site, making it non translatable. Now we download rest and build it into the website, and it will be translatable. Thanks for all your work on this Richard! For the latest/testing version it is the feed can still be used (and is now working WITH images also, still non translatable). SO the idea about the future: - when a dev or user fixes an important bug, or introduces a new feature, create a changelog entry for it including screenie. - it would be nice if the same dev also wrote some docs for that feature, so the upgrading of the docs could go a little smoother. - I also think we could use the same application to create a (huge) list of features, exactly on the same way: some text and a screenie. Any volunteers :-) ? I think we can add a 'features' feature - I'll get Ismail to work on it - please file a ticket with your requirements we can discuss further there. Regards Tim Regards, Richard Duivenvoorde ps we will move the 'projecta' site qgis.org http://qgis.org server in near future ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org mailto: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 - -- - -- Tim Sutton Visit http://kartoza.com http://kartoza.com/to find out about open source: * Desktop GIS programming services * Geospatial web development * GIS Training * Consulting Services Skype: timlinux - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP6U/oACgkQqk07qZdiYjcLBACeJuD9wjWGM7BRT3W2zZTBQxIj cM0AoIrnIjEdD19kHNVn+ASkkRglo2fr =LaF4 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Request for API change [will merge if ni claim before Aug. 26th]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Denis On 19/08/2014 15:19, Denis Rouzaud wrote: Hi all, With Matthias' work on the new edit widgets, we have some wrappers that allow using some Qt widgets as edit widgets but also some custom widgets (relation reference, color button, etc.). At first, the wrapper classes were named as widgets (e.g. QgsColorWidget). But these are not really the widgets. This brings some confusion and some naming conflicts: 1. QgsColorWidget inherits from QgsEditorWidgetWrapper. It should be named according to its functionnality. 2. We have a naming conflict: if we create a class for the widget, we can't name it properly as the name Widget is already taken. Hence, I proposed [0] to rename the widgets to wrappers. This breaks C++ API but not Python since widgets/wrappers are not available yet. This code was brought in 2.4. I am quite sure nobody used this part of the API. I know API should not be changed, and if we start making exception if can be a mess. But considering that: * it's a very narrow part of the code * that it's not available in python * it improves the readability * it will avoid naming problems in the future I am asking for this change. If nobody claims something before August 26th, the pull request [0] will be merged. Your changes seem fine to me, but no doubt someone will complain when we break APIcould you at least add a changelog entry notifying of what the API incompatibilities are? Regards Tim Greetings, Denis [0] https://github.com/qgis/QGIS/pull/1545 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - -- - -- Tim Sutton Visit http://kartoza.com http://kartoza.com/to find out about open source: * Desktop GIS programming services * Geospatial web development * GIS Training * Consulting Services Skype: timlinux - --- -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP6V2UACgkQqk07qZdiYjfpTACbB0SjaWIba9d2+uHC+Gb5mwkj iZIAn0dGuX3qGohfhzdXCovkk1o53Ic0 =EftE -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)
On Sat, Aug 23, 2014 at 8:31 AM, Nyall Dawson nyall.daw...@gmail.com wrote: On 23/08/2014 3:33 am, Even Rouault even.roua...@spatialys.com wrote: Le vendredi 22 août 2014 17:19:34, Marco Hugentobler a écrit : - Who can vote? PSC only (GDAL) / committers With GIT, 'committers' can be anyone. You probably meant folks who have push rights in official repo ? If you give them voting rights, and potentially veto right (not sure how the rules of the voting system of QGIS are), then they are defacto PSC members, since they can steer the direction of the project. Not saying this is bad. Just a consequence. I'd say neither psc nor commit rights are a good fit. While I agree that the psc should definitely have a say, not everyone on the psc is a developer or has c++ coding experience. Similarly, we have people who have commit rights who are neither developers nor psc members. I had the same impression as Nyall. PSC is meant to steer direction of the whole project, not to deal with technical details of implementations in QEPs - after all, only 3 out of 7 positions are meant for developers. At the same time I understand that creating another developer committee would make things more complex. I think that voting on QEPs could be started when the QEP's author has impression that enough consensus was reached. Most projects also allow their RFCs to go to 'deferred' state if the proposal is too controversial. Since a big part of the qep would be commenting on proposed technical architecture, I think its fairly important that developers have a good say in the process. But conversely if the qep process determines the direction of QGIS, then non devs on the psc should also have a say. Originally I thought that only new functionality would be covered by QEPs, but it is actually quite useful to have one common process for any significant changes in the project - ranging from development stuff through infrastructure changes to organizational changes (like introduction of trademark). So it makes sense to have PSC vote on QEPs. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] IT Translation broken in 2.5, it was ok in 2.4!!
Il 21/08/2014 09:28, Werner Macho ha scritto: Ah ok - now I know. Translators made me aware of some facts that are not true anymore in context help and I adjusted the information in this context help (fe4e552e) to more reflect the current state. (I know - should have been made before 2.4 release). It seems that context_help is not updated very often. As already said, IMHO context help should be removed altogether, and replaced with the relevant pages of the manual, or a link to them. All the best. -- 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
