Re: [Qgis-developer] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)
Hi, only for better understanding every details, there is a list of actual member list of PSC. And my curiosity is for the affermations: after all, only 3 out of 7 positions are meant for developers I guess a short curriculum of every psc member could help to understand the role of everyone. Also, AOAIK an important question is undrstand the limit of a RFC. Infact don't forget that the main enhancement are always covered by one or more funders. Tipically they ask an enhancement with some request themself. This RFC in the QGIS world is obviously after the real fund phase where the funders find the developer and contract him. So what mean that the RFC is submittable to the PSC ? If the PSC to accept the RFC required more changeables and these changeable require more fund, what happened ? Or this RFC could be submitted before to find the developer and fund him ? In this second situation, the RFC should be submited from the funders ? Thx, Andrea. Il 25/08/2014 07:42, Martin Dobias ha scritto: 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. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Widgets saved in qgs, not in qml
Hi all. I noticed that a field widget (in my case, hidden) is saved in a project, but not in a style: is this the intended behaviour? In my view it seems more intuitive if this would be saved in both. 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
Re: [Qgis-developer] [IE, not IS] Re: LizMap: popups broken in IS11?
Il 18/08/2014 18:05, René-Luc Dhont ha scritto: Hi Paolo, A customer reported this bug. Can you open an issue ? Done: https://github.com/3liz/lizmap-web-client/issues/81 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] IT Translation broken in 2.5, it was ok in 2.4!!
2014-08-25 7:46 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: 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. Hi Paolo, this is a good choice, just make sure that the context help is also available when a user is offline. -- Alessandro Pasotti w3: www.itopen.it ___ 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 25/08/2014 09:25, Alessandro Pasotti ha scritto: this is a good choice, just make sure that the context help is also available when a user is offline. Agreed, that's why the first choice I mentioned was replacing, instead of linking. 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
Re: [Qgis-developer] IT Translation broken in 2.5, it was ok in 2.4!!
2014-08-25 9:27 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 25/08/2014 09:25, Alessandro Pasotti ha scritto: this is a good choice, just make sure that the context help is also available when a user is offline. Agreed, that's why the first choice I mentioned was replacing, instead of linking. IMHO it sholuld be the **only** choice. Linking to online help is not an option. -- Alessandro Pasotti w3: www.itopen.it ___ 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!!
Seems to be a good task for the upcoming hackfest :) I am going to take some time with Richard anyway .. I think this could be adressed too .. regards Werner On Mon, Aug 25, 2014 at 9:57 AM, Alessandro Pasotti apaso...@gmail.com wrote: 2014-08-25 9:27 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 25/08/2014 09:25, Alessandro Pasotti ha scritto: this is a good choice, just make sure that the context help is also available when a user is offline. Agreed, that's why the first choice I mentioned was replacing, instead of linking. IMHO it sholuld be the **only** choice. Linking to online help is not an option. -- Alessandro Pasotti w3: www.itopen.it ___ 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] IT Translation broken in 2.5, it was ok in 2.4!!
This topic already added to hackfest agenda [0]. Feel free to add ideas and/or other possible solutions. [0] http://hub.qgis.org/wiki/quantum-gis/12_QGIS_Developer_Meeting_in_Essen_2014 2014-08-25 11:04 GMT+03:00 Werner Macho werner.ma...@gmail.com: Seems to be a good task for the upcoming hackfest :) I am going to take some time with Richard anyway .. I think this could be adressed too .. regards Werner On Mon, Aug 25, 2014 at 9:57 AM, Alessandro Pasotti apaso...@gmail.com wrote: 2014-08-25 9:27 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Il 25/08/2014 09:25, Alessandro Pasotti ha scritto: this is a good choice, just make sure that the context help is also available when a user is offline. Agreed, that's why the first choice I mentioned was replacing, instead of linking. IMHO it sholuld be the **only** choice. Linking to online help is not an option. -- Alessandro Pasotti w3: www.itopen.it ___ 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 -- Alexander Bruy ___ 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)
Hi Andrea, First of all, I tend to agree with Marco, where QEP should be voted when there is a general agreement on them. The PSC voting should therefore be enough. As for you question about QEP vs funders. Le lundi 25 août 2014 08:41:29, aperi2007 a écrit : [snip] Also, AOAIK an important question is undrstand the limit of a RFC. Infact don't forget that the main enhancement are always covered by one or more funders. Tipically they ask an enhancement with some request themself. This RFC in the QGIS world is obviously after the real fund phase where the funders find the developer and contract him. So what mean that the RFC is submittable to the PSC ? If the PSC to accept the RFC required more changeables and these changeable require more fund, what happened ? Or this RFC could be submitted before to find the developer and fund him ? In this second situation, the RFC should be submited from the funders ? What should happen is one of the three following scenarii : * The funder works with a contractor which knows QGIS and the QEP process well enough to guarantee to the funder that the QEP will pass as-is, for the originally proposed amount. In this case, the contractor takes the risk. * The funder provides the QEP and makes the discussions with the community until a general agreement is reached. Then the funder finds a company/developer to pass a contract for the development phase. * The funder makes a first contract with a company/developer, to write the QEP and reach an agreement (or not). Once the QEP status is set (voted as is, voted modified, deferred, rejected), the funder can pass another contract with this company/developer (or another) to implement the QEP. Vincent Thx, Andrea. Il 25/08/2014 07:42, Martin Dobias ha scritto: 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. ___ 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] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi On 25/08/2014 07:42, Martin Dobias wrote: 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. So my 2c: - From the PSC point of view the intention is that the PSC facilitate teams to work on specific areas e.g. documentation team, UX team etc. I think RFC's would probably come under Marco's remit (PSC: Code Manager). I don't think it is necessary for the whole PSC to be involved unless Marco wants help. So the normal modus operandi would be: * Marco forms an RFC review team * People submit RFC's * Review team accepts or denies the RFC's * PSC is available to resolve any disputes that may arise or aid in decision making where review team feels the impact on the project is broad. Regards Tim Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP7A2YACgkQqk07qZdiYjenOQCfbV4jpunnB4YljgRigW1q7F02 AA4AoMoe+++BE+WjG4pzL0jPKnIFqSPr =/Cer -END PGP SIGNATURE- attachment: tim.vcf___ 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)
Hell, You speak of discussion with community. This is agreement, but the only important to be sure of the work is the PSC agreement. If after 2 weeks the PSC say nothing one could start with a contract for the development ? As Marco said, and as it always has been the case in the QGIS project, the PSC vote should only be a confirmation of the community advice. If the PSC vote is contrary to the general community agreement, then we have a problem with the PSC itself. It never has been the case AFAIK. If the community do not generally agree, then there is a problem with the QEP, and it has to be either refined, or changed. Surely better could be have a +1 explicit from the PSC menbers on the docs before start the work. The PSC is there to validate the community advice, based on the expertise of the latter. If you want to have a sense of agreement before writing a RFC, then ask the community. And how PSC vot need to say that the RFC is accepted ? I think the QEP should be officially proposed to the PSC by the original author, and the PSC will have a certain amount of time (say 1 week ?) to vote. This vote should reflect the community advice. A lack of vote in the given time should lead to QEP validation. Please note also that a community discussion could bring far from the objective of the RFC. And forgot that only the PSC vote are relevant to say the RFC is accepted or not. Another question is: actually 4/7 of PSC are not technical. This mean that a RFC could be approved without that any one of technical comptents are say : ok it is compatible with actual QGIS, it don't break anything. Or evalute if what is potentially breakable is reasonable or not. Once again, the PSC vote should only be a validation of the general community advice. The required technical competences are in the community at large, and the PSC knows to trust the community. My dubt is infact. A compatibility break is a technical question ? I guess potentially no, because it is more on QGIS usability , but is technical when start to say: hey using this solution you break the past, instead if you use this other solution you don't break the past. Is not simply to evaluate this question, and without a QGIS developer expert is not easy to follow a RFC for a funder. Then the funder hires a QGIS developer to follow the RFC and make report. That's my scenario 3. Hope this clarify your questions. Others, do not hesitate to fix my understanding of the process if I am mistaken. Vincent A. 2014-08-25 10:54 GMT+02:00 Vincent Picavet vincent...@oslandia.com: Hi Andrea, First of all, I tend to agree with Marco, where QEP should be voted when there is a general agreement on them. The PSC voting should therefore be enough. As for you question about QEP vs funders. Le lundi 25 août 2014 08:41:29, aperi2007 a écrit : [snip] Also, AOAIK an important question is undrstand the limit of a RFC. Infact don't forget that the main enhancement are always covered by one or more funders. Tipically they ask an enhancement with some request themself. This RFC in the QGIS world is obviously after the real fund phase where the funders find the developer and contract him. So what mean that the RFC is submittable to the PSC ? If the PSC to accept the RFC required more changeables and these changeable require more fund, what happened ? Or this RFC could be submitted before to find the developer and fund him ? In this second situation, the RFC should be submited from the funders ? What should happen is one of the three following scenarii : * The funder works with a contractor which knows QGIS and the QEP process well enough to guarantee to the funder that the QEP will pass as-is, for the originally proposed amount. In this case, the contractor takes the risk. * The funder provides the QEP and makes the discussions with the community until a general agreement is reached. Then the funder finds a company/developer to pass a contract for the development phase. * The funder makes a first contract with a company/developer, to write the QEP and reach an agreement (or not). Once the QEP status is set (voted as is, voted modified, deferred, rejected), the funder can pass another contract with this company/developer (or another) to implement the QEP. Vincent Thx, Andrea. Il 25/08/2014 07:42, Martin Dobias ha scritto: 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
Re: [Qgis-developer] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)
Le lundi 25 août 2014 11:42:12, Vincent Picavet a écrit : Hell, I meant Hello, of course, no offence :-/ v. You speak of discussion with community. This is agreement, but the only important to be sure of the work is the PSC agreement. If after 2 weeks the PSC say nothing one could start with a contract for the development ? As Marco said, and as it always has been the case in the QGIS project, the PSC vote should only be a confirmation of the community advice. If the PSC vote is contrary to the general community agreement, then we have a problem with the PSC itself. It never has been the case AFAIK. If the community do not generally agree, then there is a problem with the QEP, and it has to be either refined, or changed. Surely better could be have a +1 explicit from the PSC menbers on the docs before start the work. The PSC is there to validate the community advice, based on the expertise of the latter. If you want to have a sense of agreement before writing a RFC, then ask the community. And how PSC vot need to say that the RFC is accepted ? I think the QEP should be officially proposed to the PSC by the original author, and the PSC will have a certain amount of time (say 1 week ?) to vote. This vote should reflect the community advice. A lack of vote in the given time should lead to QEP validation. Please note also that a community discussion could bring far from the objective of the RFC. And forgot that only the PSC vote are relevant to say the RFC is accepted or not. Another question is: actually 4/7 of PSC are not technical. This mean that a RFC could be approved without that any one of technical comptents are say : ok it is compatible with actual QGIS, it don't break anything. Or evalute if what is potentially breakable is reasonable or not. Once again, the PSC vote should only be a validation of the general community advice. The required technical competences are in the community at large, and the PSC knows to trust the community. My dubt is infact. A compatibility break is a technical question ? I guess potentially no, because it is more on QGIS usability , but is technical when start to say: hey using this solution you break the past, instead if you use this other solution you don't break the past. Is not simply to evaluate this question, and without a QGIS developer expert is not easy to follow a RFC for a funder. Then the funder hires a QGIS developer to follow the RFC and make report. That's my scenario 3. Hope this clarify your questions. Others, do not hesitate to fix my understanding of the process if I am mistaken. Vincent A. 2014-08-25 10:54 GMT+02:00 Vincent Picavet vincent...@oslandia.com: Hi Andrea, First of all, I tend to agree with Marco, where QEP should be voted when there is a general agreement on them. The PSC voting should therefore be enough. As for you question about QEP vs funders. Le lundi 25 août 2014 08:41:29, aperi2007 a écrit : [snip] Also, AOAIK an important question is undrstand the limit of a RFC. Infact don't forget that the main enhancement are always covered by one or more funders. Tipically they ask an enhancement with some request themself. This RFC in the QGIS world is obviously after the real fund phase where the funders find the developer and contract him. So what mean that the RFC is submittable to the PSC ? If the PSC to accept the RFC required more changeables and these changeable require more fund, what happened ? Or this RFC could be submitted before to find the developer and fund him ? In this second situation, the RFC should be submited from the funders ? What should happen is one of the three following scenarii : * The funder works with a contractor which knows QGIS and the QEP process well enough to guarantee to the funder that the QEP will pass as-is, for the originally proposed amount. In this case, the contractor takes the risk. * The funder provides the QEP and makes the discussions with the community until a general agreement is reached. Then the funder finds a company/developer to pass a contract for the development phase. * The funder makes a first contract with a company/developer, to write the QEP and reach an agreement (or not). Once the QEP status is set (voted as is, voted modified, deferred, rejected), the funder can pass another contract with this company/developer (or another) to implement the QEP. Vincent Thx, Andrea. Il 25/08/2014 07:42, Martin Dobias ha scritto: 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
Re: [Qgis-developer] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)
Hey, I am still of the opinion that the PSC doesn't need to be involved in the vote unless there is a split. Most QEPs will be at a technical level and might take a bit to parse, others might not be. It might be best to have categories or QEPs so that different groups have different votes. A QEP for say changing the bug tracking system could be voted by the PSC for example (example only). A QEP should come after some discussion on the mailing list. Consider it a formal proposal rather then a 'what do you think of this idea'. If you are funding a project then mailing list discussion is highly recommend because creating a QEP even if you have money and a developer is no guarantee that it will be accepted. The whole point of a QEP is to see the full idea of a proposal in one place and to make sure it will fit with the best interests of the project. Having 10 ways to do X is not and doesn't help our users. Having QEPs might slow development in the sense that you can no longer just fund something and have it go in without objection or discussion. Nathan On Aug 25, 2014 7:42 PM, Vincent Picavet vincent...@oslandia.com wrote: Hell, You speak of discussion with community. This is agreement, but the only important to be sure of the work is the PSC agreement. If after 2 weeks the PSC say nothing one could start with a contract for the development ? As Marco said, and as it always has been the case in the QGIS project, the PSC vote should only be a confirmation of the community advice. If the PSC vote is contrary to the general community agreement, then we have a problem with the PSC itself. It never has been the case AFAIK. If the community do not generally agree, then there is a problem with the QEP, and it has to be either refined, or changed. Surely better could be have a +1 explicit from the PSC menbers on the docs before start the work. The PSC is there to validate the community advice, based on the expertise of the latter. If you want to have a sense of agreement before writing a RFC, then ask the community. And how PSC vot need to say that the RFC is accepted ? I think the QEP should be officially proposed to the PSC by the original author, and the PSC will have a certain amount of time (say 1 week ?) to vote. This vote should reflect the community advice. A lack of vote in the given time should lead to QEP validation. Please note also that a community discussion could bring far from the objective of the RFC. And forgot that only the PSC vote are relevant to say the RFC is accepted or not. Another question is: actually 4/7 of PSC are not technical. This mean that a RFC could be approved without that any one of technical comptents are say : ok it is compatible with actual QGIS, it don't break anything. Or evalute if what is potentially breakable is reasonable or not. Once again, the PSC vote should only be a validation of the general community advice. The required technical competences are in the community at large, and the PSC knows to trust the community. My dubt is infact. A compatibility break is a technical question ? I guess potentially no, because it is more on QGIS usability , but is technical when start to say: hey using this solution you break the past, instead if you use this other solution you don't break the past. Is not simply to evaluate this question, and without a QGIS developer expert is not easy to follow a RFC for a funder. Then the funder hires a QGIS developer to follow the RFC and make report. That's my scenario 3. Hope this clarify your questions. Others, do not hesitate to fix my understanding of the process if I am mistaken. Vincent A. 2014-08-25 10:54 GMT+02:00 Vincent Picavet vincent...@oslandia.com: Hi Andrea, First of all, I tend to agree with Marco, where QEP should be voted when there is a general agreement on them. The PSC voting should therefore be enough. As for you question about QEP vs funders. Le lundi 25 août 2014 08:41:29, aperi2007 a écrit : [snip] Also, AOAIK an important question is undrstand the limit of a RFC. Infact don't forget that the main enhancement are always covered by one or more funders. Tipically they ask an enhancement with some request themself. This RFC in the QGIS world is obviously after the real fund phase where the funders find the developer and contract him. So what mean that the RFC is submittable to the PSC ? If the PSC to accept the RFC required more changeables and these changeable require more fund, what happened ? Or this RFC could be submitted before to find the developer and fund him ? In this second situation, the RFC should be submited from the funders ? What should happen is one of the three following scenarii : * The funder works with a contractor which knows QGIS and the QEP process well enough to guarantee to the
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] Resurrecting the RFC (QEP - QGIS Enhancement Proposal)
What mean the community dont agree ? More explain. If 3 or 4 user community say no or ask different solutions . It is the community think ? I guess the PSC should not ne only a simply executor of the community think, but the real director of the project. Often the community think a thing bit thw more strategic solution is another. I guess the server side is always minority on user interest. And often the user font understand what is a server question. So the community never choose a server solution. This mean in the medium time to split the qgis in two distincts products. Desktop and server. Every one with its own community. My 1 ct. :) Il 25/ago/2014 11:35 Tim Sutton t...@kartoza.com ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi On 25/08/2014 07:42, Martin Dobias wrote: 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. So my 2c: - From the PSC point of view the intention is that the PSC facilitate teams to work on specific areas e.g. documentation team, UX team etc. I think RFC's would probably come under Marco's remit (PSC: Code Manager). I don't think it is necessary for the whole PSC to be involved unless Marco wants help. So the normal modus operandi would be: * Marco forms an RFC review team * People submit RFC's * Review team accepts or denies the RFC's * PSC is available to resolve any disputes that may arise or aid in decision making where review team feels the impact on the project is broad. Regards Tim Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP7A2YACgkQqk07qZdiYjenOQCfbV4jpunnB4YljgRigW1q7F02 AA4AoMoe+++BE+WjG4pzL0jPKnIFqSPr =/Cer -END PGP SIGNATURE- ___ 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] Qgis-developer Digest, Vol 101, Issue 59
Hi All The feature of saving styles and .ui forms in a pg/splite database seems very useful but somehow I can not load any .ui forms from my database. I successfully saved a .ui form into the database and now I find it in layer_styles.ui. But the tag editform (layer_styles.styleQML) is pointing to the original .ui-file. How can I change editform to point to the .ui form saved in the database? Regards Josef ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] DimLao plugin has no code repository... please check!
Hi, I found that a new plugin DimLao Has no code repo and description https://plugins.qgis.org/plugins/dimlao/ regards, Luigi Pirelli ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Qgis-developer Digest, Vol 101, Issue 59
probably it's better to change the subject of the thread in something more useful about saving ui in SL, if confirmed, could you prepare test data or prepare a description of the problem filing a tiket? regards, Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com) On 25 August 2014 14:19, josef k groundwater...@gmail.com wrote: Hi All The feature of saving styles and .ui forms in a pg/splite database seems very useful but somehow I can not load any .ui forms from my database. I successfully saved a .ui form into the database and now I find it in layer_styles.ui. But the tag editform (layer_styles.styleQML) is pointing to the original .ui-file. How can I change editform to point to the .ui form saved in the database? Regards Josef ___ 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
[Qgis-developer] Python plugins mandatory metadata
Hi, It seems like most of us are still confused about mandatory metadata in Python plugins. There have been a lot of discussions on this topic in the past and I would like to resume the discussion. IIRC the most debated questions were: * if homepage must be mandatory * if tracker must be mandatory * if repository must be mandatory We somewhat agreed about leaving those metadata optional but highly recommended, this means that the automatic validator still accepts the plugin but a warning is shown to the author and to website staff users. The plugin approval is not automatic, if somebody thinks that for a particular plugin one of those metadata are absolutely necessary he/she can just unapprove the plugin. I'm still convinced that the a.m. metadata should be recommended but not mandatory but of course we can change this policy. If I missed the point in which a different decision was taken, please let me know and I will add those rules to the validator. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Python plugins mandatory metadata
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi On 25/08/2014 17:01, Alessandro Pasotti wrote: Hi, It seems like most of us are still confused about mandatory metadata in Python plugins. There have been a lot of discussions on this topic in the past and I would like to resume the discussion. IIRC the most debated questions were: * if homepage must be mandatory * if tracker must be mandatory * if repository must be mandatory We somewhat agreed about leaving those metadata optional but highly recommended, this means that the automatic validator still accepts the plugin but a warning is shown to the author and to website staff users. The plugin approval is not automatic, if somebody thinks that for a particular plugin one of those metadata are absolutely necessary he/she can just unapprove the plugin. I'm still convinced that the a.m. metadata should be recommended but not mandatory but of course we can change this policy. If I missed the point in which a different decision was taken, please let me know and I will add those rules to the validator. I agree they should remain optional for now. Regards Tim - -- - -- 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlP7UOEACgkQqk07qZdiYjerFwCeNJ9LTGXxE5KY9frDtPRkMqKL vjQAoNPLSM5d6Z38dlZLFHwWC82cymUX =x2uO -END PGP SIGNATURE- attachment: tim.vcf___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Identify results form vs feature form
Dear all, up to QGIS 2.2 there was an Option in Settings - Options - Map Tools, identify section: Open feature form, if a single feature is identified I can not find that option in QGIS 2.4 and QGIS dev anymore. It is still in the lastest docs http://docs.qgis.org/testing/en/docs/user_manual/introduction/qgis_configuration.html#options and it still behaves the same way. But to change the behaviour, I have to start my still working copy of QGIS 2.2 or QGIS 2.0. I guess this is not intended. Am I missing something well-hidden? Greetings, André Joost ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Python plugins mandatory metadata
Hi all. Il 25/08/2014 17:06, Tim Sutton ha scritto: I agree they should remain optional for now. After a few months of managing the plugin approval queue, I still do not understand what is the advantage of having plugins without a repo and bugtracker. I agree that a home page is not a necessity. 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
Re: [Qgis-developer] Identify results form vs feature form
Hi André, On Mon, 25. Aug 2014 at 17:26:02 +0200, Andre Joost wrote: Open feature form, if a single feature is identified I can not find that option in QGIS 2.4 and QGIS dev anymore. It's in the identify dialog now. It is still in the lastest docs http://docs.qgis.org/testing/en/docs/user_manual/introduction/qgis_configuration.html#options Sounds like a bug. Am I missing something well-hidden? IMHO if the objective was to hide it, Nathan miseably failed at it ;) 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] Python plugins mandatory metadata
2014-08-25 17:29 GMT+02:00 Paolo Cavallini cavall...@faunalia.it: Hi all. Il 25/08/2014 17:06, Tim Sutton ha scritto: I agree they should remain optional for now. After a few months of managing the plugin approval queue, I still do not understand what is the advantage of having plugins without a repo and bugtracker. I agree that a home page is not a necessity. Paolo, of course the question is not wether is there an advantage but on the contrary if is there a penalty without that informations. IMHO the answer: most of the times yes, but not always. For simpler plugin, a repository is probably not particularly useful nor is a bug tracker. But since the final approval step is human-driven, nobody stops you from unapproving a particular plugin if you really miss one of that metadata. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Python plugins mandatory metadata
Hello, Hi all. Il 25/08/2014 17:06, Tim Sutton ha scritto: I agree they should remain optional for now. After a few months of managing the plugin approval queue, I still do not understand what is the advantage of having plugins without a repo and bugtracker. I agree that a home page is not a necessity. +1 Moreover, plugins are GPL licenced, hence the source code should be shared when a plugin is distributed. Python is a script language, but still there are some source which should not go into the final plugin package (.ui files typically). Therefore, a plugin _must_ have a full source code available somewhere, and a repository is a logical place for this. Globally it is about improving the global quality of the software, and these steps are the basics a plugin developer should provide. Vincent ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Python plugins mandatory metadata
2014-08-25 17:46 GMT+02:00 Vincent Picavet vincent...@oslandia.com: Hello, Hi all. Il 25/08/2014 17:06, Tim Sutton ha scritto: I agree they should remain optional for now. After a few months of managing the plugin approval queue, I still do not understand what is the advantage of having plugins without a repo and bugtracker. I agree that a home page is not a necessity. +1 Moreover, plugins are GPL licenced, hence the source code should be shared when a plugin is distributed. Python is a script language, but still there are some source which should not go into the final plugin package (.ui files typically). This is not always the case, I know at least one plugin without ui files. But the question is not if a plugin generally needs a repository/tracker, of course it does. The question is if a plugin can be uploaded in the official plugins repository even if it misses a repository/tracker. There is some automatic validation in place and automatic rules do not admit exceptions. -- Alessandro Pasotti w3: www.itopen.it ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis.org repository public key for Ubuntu expired
Hi, Well, I did follow these guidelines (which proved successful earlier on), but I recently get these error messages which have to do with the expiration of the public key. I have the same issue in Linux Mint Qiana as well. Hopefully someone can take a closer look. Op 22-08-14 om 11:51 schreef Jürgen E. Fischer: Hi, On Fri, 22. Aug 2014 at 11:35:12 +0200, fsLori wrote: Hi there, I see that the public key mentioned on the website (http://downloads.qgis.org/en/site/forusers/alldownloads.html#ubuntu) has expired. You didn't verify that before posting. ;) Jürgen Original message Onderwerp: qgis.org repository public key for Ubuntu expired Datum: Fri, 22 Aug 2014 11:35:12 +0200 Van:fsLori Aan:qgis-developer@lists.osgeo.org Hi there, I see that the public key mentioned on the website (http://downloads.qgis.org/en/site/forusers/alldownloads.html#ubuntu) has expired. I use Ubuntu Precise and was successful before to use the qgis repository ( deb http://qgis.org/debian precise main). But now I get an error when updating my package list against the qgis.org repo for ubuntu precise. My current QGIS is at 2.4.0 and this is an extract from the output (Dutch) from the 'apt-key list' command, from which it seems that the key has expired since 18 August: pub 1024R/47765B75 2013-08-18 [verlopen: 2014-08-18] uid Quantum GIS Archive Automatic Signing Key (2013) qgis-developer@lists.osgeo.org Obviously, reinstalling the same key did not help. Hopefully somebody can handle this! ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis.org repository public key for Ubuntu expired
Hi fsLori, On Mon, 25. Aug 2014 at 18:45:25 +0200, fsLori wrote: Well, I did follow these guidelines (which proved successful earlier on), but I recently get these error messages which have to do with the expiration of the public key. I have the same issue in Linux Mint Qiana as well. The key mentioned on http://downloads.qgis.org/en/site/forusers/alldownloads.html#ubuntu is DD45F6C3 not 47765B75 - and that was already the case when you posted, although not long. 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] qgis.org repository public key for Ubuntu expired
Thanks for this key Jürgen. And now I do find the updated key on the site you mentioned! fsLori Op 25-08-14 om 18:49 schreef Jürgen E. Fischer: Hi fsLori, On Mon, 25. Aug 2014 at 18:45:25 +0200, fsLori wrote: Well, I did follow these guidelines (which proved successful earlier on), but I recently get these error messages which have to do with the expiration of the public key. I have the same issue in Linux Mint Qiana as well. The key mentioned on http://downloads.qgis.org/en/site/forusers/alldownloads.html#ubuntu is DD45F6C3 not 47765B75 - and that was already the case when you posted, although not long. Jürgen ___ 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] Identify results form vs feature form
Am 25.08.2014 17:34, schrieb Jürgen E. Fischer: Hi André, On Mon, 25. Aug 2014 at 17:26:02 +0200, Andre Joost wrote: Open feature form, if a single feature is identified I can not find that option in QGIS 2.4 and QGIS dev anymore. It's in the identify dialog now. There is an option to show the feature form and a checkbox Auto open form , yes. It's not easy to understand that checking that will open the feature form for single features. If I set the checkbox, I have no chance to get the identify result form back if my layers contain only single features. The old option method looked somewhat more logical to me. Any chance to get it back? It would not harm anybody, and the docs are correct again. It is still in the lastest docs http://docs.qgis.org/testing/en/docs/user_manual/introduction/qgis_configuration.html#options Sounds like a bug. If you click the Help button of the identify form, it also tells me about the old options. Am I missing something well-hidden? IMHO if the objective was to hide it, Nathan miseably failed at it ;) Perhaps we should give him a second chance ;-) Greetings, André Joost ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] DimLao plugin has no code repository... please check!
Il 25/08/2014 16:49, Luigi Pirelli ha scritto: Hi, I found that a new plugin DimLao Has no code repo and description https://plugins.qgis.org/plugins/dimlao/ And the bugtracker returns an Access denied. Thanks for noticing. Could the author please fix this? 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
[Qgis-developer] load .ui forms from spatialite DB
Hi Luigi I have no problems saving layer style and a .ui to spatialite DB. I can also load the style back from SL. But I can not find how to load the ui form. I am not sure if it is just me who can not find this hidden feature or if it is actually missing. Can someone please confirm this and I will create a bug report. regards Josef 2014-08-25 16:54 GMT+02:00 Luigi Pirelli lui...@gmail.com: probably it's better to change the subject of the thread in something more useful about saving ui in SL, if confirmed, could you prepare test data or prepare a description of the problem filing a tiket? regards, Luigi Pirelli (luigi.pire...@faunalia.it - lui...@gmail.com) On 25 August 2014 14:19, josef k groundwater...@gmail.com wrote: Hi All The feature of saving styles and .ui forms in a pg/splite database seems very useful but somehow I can not load any .ui forms from my database. I successfully saved a .ui form into the database and now I find it in layer_styles.ui. But the tag editform (layer_styles.styleQML) is pointing to the original .ui-file. How can I change editform to point to the .ui form saved in the database? Regards Josef ___ 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] Python plugins mandatory metadata
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/08/2014 17:46, Vincent Picavet wrote: Hello, Hi all. Il 25/08/2014 17:06, Tim Sutton ha scritto: I agree they should remain optional for now. After a few months of managing the plugin approval queue, I still do not understand what is the advantage of having plugins without a repo and bugtracker. I agree that a home page is not a necessity. +1 Moreover, plugins are GPL licenced, hence the source code should be shared when a plugin is distributed. Python is a script language, but still there are some source which should not go into the final plugin package (.ui files typically). Therefore, a plugin _must_ have a full source code available somewhere, and a repository is a logical place for this. Globally it is about improving the global quality of the software, and these steps are the basics a plugin developer should provide. Yes but there are always going to be exceptions to this and I dont believe we should make having these items a sticking point e.g.: * some one in a corporate environment can't easily make a website for the plugin they write * Someone in a coprporate environment works in a repo behind a firewall * a bug tracker is behind a corporate firewall As Ale says, its not that we should encourage people not to have these things, but we should not penalise them for it unduly if they don't. I think there are other things that would be more interesting to mandate e.g.: * standardised documentation * HIG compliance * Including a license file etc. I would still like to see us reach a point where we have 'best of breed', 'sanctioned' plugins, and the 'wild west' differentiated for the users. Regards Tim Vincent ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlP7kLsACgkQqk07qZdiYjd3oQCfXty1OR7OcrPqMpeEDL81E9Sz 1UwAnRMiQ++zIK9lgFXN4uOSVY2lCpFd =OYHU -END PGP SIGNATURE- attachment: tim.vcf___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Python plugins mandatory metadata
Since I'm not a contributor to the main project, just some plugins, I'm not sure my voice will count for much but I think Tim hits on an important point. As as a developer of plugins for my company, I have created repos and bug trackers for the plugins I created because I was asked to but they are not regularly used, watched or maintained. If anything they are worse than none at all. I understand the interest in standard documentation, but even that is often less than ideal from a companies perspective. Speaking generally companies provide plugins for two reasons. First, they are something the company needs and is willing to share with others. Second, they are useful tools for the company's clients to use with the companies commercial tools or services. In both cases plugins are, to some extent, a means to promote the company so hosting documentation on the company site is more valuable to the company then distributing all of it with the plugin. I would encourage QGIS developers to try to keep balanced requirements to ensure that corporate, academic and volunteer contributors and users can all benefit. TSW On Mon, Aug 25, 2014 at 1:38 PM, Tim Sutton t...@kartoza.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25/08/2014 17:46, Vincent Picavet wrote: Hello, Hi all. Il 25/08/2014 17:06, Tim Sutton ha scritto: I agree they should remain optional for now. After a few months of managing the plugin approval queue, I still do not understand what is the advantage of having plugins without a repo and bugtracker. I agree that a home page is not a necessity. +1 Moreover, plugins are GPL licenced, hence the source code should be shared when a plugin is distributed. Python is a script language, but still there are some source which should not go into the final plugin package (.ui files typically). Therefore, a plugin _must_ have a full source code available somewhere, and a repository is a logical place for this. Globally it is about improving the global quality of the software, and these steps are the basics a plugin developer should provide. Yes but there are always going to be exceptions to this and I dont believe we should make having these items a sticking point e.g.: * some one in a corporate environment can't easily make a website for the plugin they write * Someone in a coprporate environment works in a repo behind a firewall * a bug tracker is behind a corporate firewall As Ale says, its not that we should encourage people not to have these things, but we should not penalise them for it unduly if they don't. I think there are other things that would be more interesting to mandate e.g.: * standardised documentation * HIG compliance * Including a license file etc. I would still like to see us reach a point where we have 'best of breed', 'sanctioned' plugins, and the 'wild west' differentiated for the users. Regards Tim Vincent ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org 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 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlP7kLsACgkQqk07qZdiYjd3oQCfXty1OR7OcrPqMpeEDL81E9Sz 1UwAnRMiQ++zIK9lgFXN4uOSVY2lCpFd =OYHU -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Trevor Wiens Apropos Information Systems aproposinfosystems.com Calgary, Alberta Ph. 403-973-5901 Fax 780-666-4580 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Identify results form vs feature form
Hi, The reason I moved the option is because it wasn't really a option in the first place. Something like that doesn't belong in the options dialog as it can be changed more then once during a session, and if you are having to visit the options dialog for that then it's in the wrong place. Anything found in Settings - Options should not have to be changed a lot, set once and forget. The old method was also inconsistent, sometimes you might not want the feature form to open for a single feature but you got it regardless unless you did the Settings - Options dance to change it for a single use case. I agree that getting the identify results dock back is not the best, however moving the settings back to Options is not the solution. I am thinking a Open Result Pane button next to the identity map tool button. The recommend workflow is to leave the identify result dock open, put it in a tab if you need, and control the settings for identity from there. They will persist between sessions just like the last settings. The identify result dock will always show the current results regardless of if the feature form is shown or not. This is to make it more consistent from a users point of view as the tool always does the same action regardless, showing the results. Opening the feature form is a bonus on top of the standard function not in replace of. It was never about hiding the options. In fact quite the opposite. Moving them to the dock now give you more live control on a need by need basis rather then Settings - Options...dance if you need to change it for a session. Regards, Nathan On Tue, Aug 26, 2014 at 3:22 AM, Andre Joost andre+jo...@nurfuerspam.de wrote: Am 25.08.2014 17:34, schrieb Jürgen E. Fischer: Hi André, On Mon, 25. Aug 2014 at 17:26:02 +0200, Andre Joost wrote: Open feature form, if a single feature is identified I can not find that option in QGIS 2.4 and QGIS dev anymore. It's in the identify dialog now. There is an option to show the feature form and a checkbox Auto open form , yes. It's not easy to understand that checking that will open the feature form for single features. If I set the checkbox, I have no chance to get the identify result form back if my layers contain only single features. The old option method looked somewhat more logical to me. Any chance to get it back? It would not harm anybody, and the docs are correct again. It is still in the lastest docs http://docs.qgis.org/testing/en/docs/user_manual/introduction/qgis_ configuration.html#options Sounds like a bug. If you click the Help button of the identify form, it also tells me about the old options. Am I missing something well-hidden? IMHO if the objective was to hide it, Nathan miseably failed at it ;) Perhaps we should give him a second chance ;-) Greetings, André Joost ___ 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] DimLao plugin has no code repository... please check!
Strange. There is a repository tag: https://bitbucket.org/edigonzales/qgis_dimlao/src/f459baa2c67cdbe2ec48a249e406cd3faa33e7a0/metadata.txt?at=master But it does not show in the plugin repo. Regards Stefan -Ursprüngliche Nachricht- Von: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer- boun...@lists.osgeo.org] Im Auftrag von Paolo Cavallini Gesendet: Montag, 25. August 2014 19:48 An: qgis-developer@lists.osgeo.org Betreff: Re: [Qgis-developer] DimLao plugin has no code repository... please check! Il 25/08/2014 16:49, Luigi Pirelli ha scritto: Hi, I found that a new plugin DimLao Has no code repo and description https://plugins.qgis.org/plugins/dimlao/ And the bugtracker returns an Access denied. Thanks for noticing. Could the author please fix this? 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 ___ 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
