Re: [Qgis-developer] [Qgis-user] Stress about release plans
I´ve now been using-, bug reporting- and making tutorials for QGIS since 1.7 and I still find it difficult to make stable contributions in several ways: In this tread everyone write ‘more money’ or ‘Work together’ I want to donate time – but find it difficult to find a limited project. As everyone else I have a time consuming job, but find it both exiting and needed to be a part of this ‘movement’ What if we under Support on the front page make it easy to support in several ways: -We make a matrix for testing for users. Having a set of standard data. A platform (windows/linux/MAC) and then a list of functions to test. I´m sure we are several users who would gladly take a job like this if it is limited and organized – because we can see the job being done and developers taking over. In one of my courses I introduced this to my students – they also found it brilliant to be able to participate. - We make an addition to tutorials: Case based tutorials, where we can write a small summary/intro – incl. platform and version. Upload data and tutorial in our own form.( I don´t have time to re-write into a standard format) - We make more exposure about the donation page. It is set on the front page – Good – but also mention it for our students, users of all kind - to donate. Micro donations in the students beer-hut will be my next battle ☺ I love being a part of QGIS!!! Regards Lene Fischer ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Il 23/07/2014 08:58, Lene Fischer ha scritto: I´ve now been using-, bug reporting- and making tutorials for QGIS since 1.7 and I still find it difficult to make stable contributions in several ways: In this tread everyone write ‘more money’ or ‘Work together’ I want to donate time – but find it difficult to find a limited project. As everyone else I have a time consuming job, but find it both exiting and needed to be a part of this ‘movement’ What if we under Support on the front page make it easy to support in several ways: Agreed fully: once we devise a way to make it easy, people respond quite positively. E.g. the new donate while downloading stuff is attracting an unprecedented number of small donations. Please help setting this up. I love being a part of QGIS!!! We all do, isn't it? ;) Thanks for your suggestions. -- 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] Stress about release plans
Hi, I like to add my opinion just to remeber that QGIS is using many other compoent. One as example for many : gdal or geos. But I coud speak equally of spatialite, saga, and so on. You question are all right. But speak always of qgis as a unique molotithic software.This is not true. sometime the problem is not on qgis software , but in other way (gdal, geos, spatialite, and so on...) so what happened when the bug is related to geos ? of to gdal ? The bug fixer of qgis could only say. This is not my question. But for the user that fund the bg fix the problem is a qgis problem. It has not fund the resolution on gdal or on geos. So before to fund is necessary to know where is the problem really. Otherwise the fund is lost. Or bad-est solution the bug fixer try to copy the code inside the qgis to bug fixe that copy. So the bugfix of a software like qgis is absolutely not easy. develope new feature is surely ore easy rather than fix them. And the not monolithic approach of qgis is not help the bug fix question. Regards, Andrea. 2014-07-23 7:47 GMT+02:00 Tim Sutton t...@kartoza.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi On 22/07/2014 22:50, Bo Victor Thomsen wrote: Just to stretch my point - * I'm not argumenting for a regular LTS version in parallel with a development version including back-porting and patching to several versions of QGIS. I have developed software for 30 years; I know the efforts and pains of parallel versions :-/ * I'm trying to make a case for taking every *third* development cycle and *minimizing* the addition of new features in this cycle and *maximizing *the bug fixing/testing/documentation effort. Right this is what I have proposed in the past (e.g. https://www.mail-archive.com/qgis-developer@lists.osgeo.org/msg22449.html). I think that keeping our current release cadence and just attaching special criteria (e.g. only one month of feature commits, 3 months bug fixing and feature freeze) to intermittent releases is the simplest way to provide a yearly 'stable' version of QGIS without needing to change developer behaviour or require any more resources. * Have a clean-up period for around one month after the bug-fix version release. In this period every new bug fix should be added to both the bug-fix release and the new developer release (OK, some parallel patching to 2 QGIS versions). We have been working on getting one paid developer day for stabilisation and release work pre month for the next 9 months via the InaSAFE project. If others could club together and do the same, I believe it could make a huge impact on the stability of QGIS with rather small investment by individual organisations. There are many god developers on our team that are available for such work and life will be much easier for them if they can put aside some time to work on stabilisation without needing to worry about how to keep their lights on. * After the clean-up period there would be a mandatory point release of the bug-fix release. And after that: No further work on this bug-fix version. Juergen has already tabled an approach for doing bugfix releases after backports/bugfixes have been made to the current release branch (and no bugfix release if no backports / bugfixes have been made). He can explain better the concept, but it really needs also some impetus from those sponsoring developers to do work to also request that the bugfixes they sponsor get backported. We can discuss the details and length of the different periods. But the main points is for every third development cycle: A minimum of new features and a maximum effort in bug-fixing/testing/translation/tutorials/documentation, i.e: all the secondary efforts in making good and stable software. With the current cycle periods there would be one bug-fix version every year. This period coincide - in my experience - with the minimum accepted time periods between software version updates in most large organisations. I would like to mention that although it may not seem like it sometimes (mostly because of the fact that we have had this discussion so many times and any particular approach we take someone always has a big issue with), the QGIS team *are* very interested in getting a high quality and stable release into play, we just need to balance that with the fact that a) developers are largely undirected by the central project and focus on things they or their clients are interested in and b) we have extremely limited resources and much of the core project work is undertaken on a voluntary basis by a handful of team members. So any suggested route has to take into the account that you are asking already overstretched volunteers to take on more work, possibly diluting their efforts further on other areas of the project. So yes throwing money at the problem does not necessarily solve all problems, but it certainly will help us actually manage the parts of
Re: [Qgis-developer] Stress about release plans
Il 22/07/2014 21:01, Andrew ha scritto: It a chicken/egg problem. We need to have some stable, relatively bug free version of QGIS with predictable (and somewhat slow ) release cycles before it's acceptable in large organisations (with money to spend on development/bug fixing). I think this is true, though I dont have experience with large organizations. As a user i would love to have a more stable LTS version and if i could i would earmark my donations specifically for supporting an LTS and, i think, would contribute more. But since it earmarking donations would put a significant additional strain on our time (remember, nobody pays for the infrastructure, including financial aspects, so it's all voluntary work). we believe PSC has a sufficient understanding of the project to allocate our (very limited!) resources in the best interests of QGIS. in fact, we are asking donors: trust us, your donations will be handled for the good of the project, and frankly I believe we've been quite effective on this until now. having said that, I would like to find a simple way of implementing preferential donations (you vote with your money). doesnt exist, i cant help fund it with my small donations. Also, that is something that i might be able to get my work to donate small amounts for, though as a small grant-funded non-profit costs that are not directly billable to grants are very hard to pay for. We can issue receipts for significant donations (no, please don't ask a bill for a 5 € donation :) ). All the best, and 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] [Qgis-user] Stress about release plans
Hi Simon, this sounds like a very good idea to me. At the moment documenters look at the commit logs for a [FEATURE] comment and add it to a wiki list. Then search through all mls, wikis and blogs, if there is some howto available or at a least a short discussion or description about that feature. If not we have to ask for help - all this takes time... If we have a simple skeleton about the feature automatically provided by developers, we would be happy and it would be much easier to write a better documentation. Regards, Otto Am Wed, 23 Jul 2014 13:41:08 +1000 schrieb Simon Cropper simoncrop...@fossworkflowguides.com: Hi All, It is hard to figure out where in the conversation to interject but Victors counter-suggestion appears appropriate to me. Being involved in several open source projects, creating tutorials for these and having in the past been involved with trying to contribute to the main documentation for these packages it is obvious to me that developers need to be involved in documentation. Users rarely are able to decipher code and trying to figure out when and how to use a particular feature can be quite daunting even for the most experienced person. Developers must provide at least basic information on what each new feature does and what each feature (drop down box, radio button, etc) is for. Without this users need to ferret through hundreds of emails and forum posts, and pester the developers anyway. It is easier for devs to provide a simple skeleton -- this does this, that does that, here is a link, check out this bug etc. All this information is available at the developers fingertips while they are working on the new feature anyway -- it is just committing 30 minutes at the end to put some details down on he page. With this basic information, documenters are better equipped to present the feature in context and explain how it should be used. On 22/07/14 20:01, Victor Olaya wrote: +1 to what Otto said. Very good point. Those creating training materials should coordinate and help the core QGIS documentation (both the manual and the training manual) improve. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. -1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet. Let's encourage developers to commit features when they are well documented, but let's also give some flexibility, since that's not always going to be possible. my 2 cents Cheers Víctor -- Geoinformatikbüro Dassau - http://www.gbd-consult.de FOSSGIS consulting , training , support and analysis Ackerstrasse 144c , D - 40233 Düsseldorf , Germany Tel: +49-(0)211-47468178 , Mobil: +49-(0)171-4687540 -- Community 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] compile error
On Tue, Jul 22, 2014 at 2:06 PM, Jürgen E. j...@norbit.de wrote: Hi Andreas, On Tue, 22. Jul 2014 at 11:53:14 +, Andreas Neumann wrote: same problem here. qscimod4.sip is not available on my machine and I don't know which ubuntu package would contain this file. That's a debian bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755491) The sip files are not currently packaged. Just for the record, I have opened a similar bug report in ubuntu: https://bugs.launchpad.net/ubuntu/+source/qscintilla2/+bug/1346197 As a workaround I included them in QGIS [8f0b8987 7e815cad] - but only the latest version (in debian) - which could have worked for older ones as well, if Qscintillas API was stable enough. Apparently it isn't. The nightly builds failed with precise already - saucy and trust worked however, but that's as far as it got as of now. I'll check what else I can do, once I now which other distributions are affected. Indeed it seems to be quite fragile. When I used SIP files from 2.8.3 together with binaries from 2.8.1, it compiled fine, but crashed QGIS during initialization. Only using SIP files from exactly the same version worked. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
We could make a script to just pull out everything with [FEATURE] in the commit between a date range if that will help. Maybe we could create stubs in Tims changelog system using something like this. - Nathan On Wed, Jul 23, 2014 at 5:28 PM, Otto Dassau das...@gbd-consult.de wrote: Hi Simon, this sounds like a very good idea to me. At the moment documenters look at the commit logs for a [FEATURE] comment and add it to a wiki list. Then search through all mls, wikis and blogs, if there is some howto available or at a least a short discussion or description about that feature. If not we have to ask for help - all this takes time... If we have a simple skeleton about the feature automatically provided by developers, we would be happy and it would be much easier to write a better documentation. Regards, Otto Am Wed, 23 Jul 2014 13:41:08 +1000 schrieb Simon Cropper simoncrop...@fossworkflowguides.com: Hi All, It is hard to figure out where in the conversation to interject but Victors counter-suggestion appears appropriate to me. Being involved in several open source projects, creating tutorials for these and having in the past been involved with trying to contribute to the main documentation for these packages it is obvious to me that developers need to be involved in documentation. Users rarely are able to decipher code and trying to figure out when and how to use a particular feature can be quite daunting even for the most experienced person. Developers must provide at least basic information on what each new feature does and what each feature (drop down box, radio button, etc) is for. Without this users need to ferret through hundreds of emails and forum posts, and pester the developers anyway. It is easier for devs to provide a simple skeleton -- this does this, that does that, here is a link, check out this bug etc. All this information is available at the developers fingertips while they are working on the new feature anyway -- it is just committing 30 minutes at the end to put some details down on he page. With this basic information, documenters are better equipped to present the feature in context and explain how it should be used. On 22/07/14 20:01, Victor Olaya wrote: +1 to what Otto said. Very good point. Those creating training materials should coordinate and help the core QGIS documentation (both the manual and the training manual) improve. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. -1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet. Let's encourage developers to commit features when they are well documented, but let's also give some flexibility, since that's not always going to be possible. my 2 cents Cheers Víctor -- Geoinformatikbüro Dassau - http://www.gbd-consult.de FOSSGIS consulting , training , support and analysis Ackerstrasse 144c , D - 40233 Düsseldorf , Germany Tel: +49-(0)211-47468178 , Mobil: +49-(0)171-4687540 -- Community Advisor - QGIS Project Steering Committee ___ Qgis-user mailing list qgis-u...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-user ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
Hi Nathan, thanks for the offer, but this is not the problem. After feature freeze we currently do a git log --since=date --grep='FEATURE', that's ok. And Tims changelog is also very helpful and often already fine as a beginning. The result is in the wiki: http://hub.qgis.org/wiki/17/ManualTasks But this covers not all changes we need to document nor does it usually describe the usage. We still we have to search the web, so it would be great to have a simple skeleton with a short description of all functionality of a feature from the developers, if that is possible. Maybe we can offer 2 ways. If developers write about features in their blog and describe how it works, as you do, you could just add the link somewhere where documenters can look it up. For others a simple documentation skeleton could be used as a standard. Whatever we finally use, it would be good to improve the current procedure. Regards Otto Am Wed, 23 Jul 2014 17:43:51 +1000 schrieb Nathan Woodrow madman...@gmail.com: We could make a script to just pull out everything with [FEATURE] in the commit between a date range if that will help. Maybe we could create stubs in Tims changelog system using something like this. - Nathan On Wed, Jul 23, 2014 at 5:28 PM, Otto Dassau das...@gbd-consult.de wrote: Hi Simon, this sounds like a very good idea to me. At the moment documenters look at the commit logs for a [FEATURE] comment and add it to a wiki list. Then search through all mls, wikis and blogs, if there is some howto available or at a least a short discussion or description about that feature. If not we have to ask for help - all this takes time... If we have a simple skeleton about the feature automatically provided by developers, we would be happy and it would be much easier to write a better documentation. Regards, Otto Am Wed, 23 Jul 2014 13:41:08 +1000 schrieb Simon Cropper simoncrop...@fossworkflowguides.com: Hi All, It is hard to figure out where in the conversation to interject but Victors counter-suggestion appears appropriate to me. Being involved in several open source projects, creating tutorials for these and having in the past been involved with trying to contribute to the main documentation for these packages it is obvious to me that developers need to be involved in documentation. Users rarely are able to decipher code and trying to figure out when and how to use a particular feature can be quite daunting even for the most experienced person. Developers must provide at least basic information on what each new feature does and what each feature (drop down box, radio button, etc) is for. Without this users need to ferret through hundreds of emails and forum posts, and pester the developers anyway. It is easier for devs to provide a simple skeleton -- this does this, that does that, here is a link, check out this bug etc. All this information is available at the developers fingertips while they are working on the new feature anyway -- it is just committing 30 minutes at the end to put some details down on he page. With this basic information, documenters are better equipped to present the feature in context and explain how it should be used. On 22/07/14 20:01, Victor Olaya wrote: +1 to what Otto said. Very good point. Those creating training materials should coordinate and help the core QGIS documentation (both the manual and the training manual) improve. The solution is very simple: Require up to date, accurate documentation for all commits of new features. This is one for the PSC. After all, what's the point in having tons of features if no-one knows how to use them or what they do? Will it slow down new feature feature commit? Probably, but I figure that's a small price to pay for actually having documentation. And from that documentation, universal training materials can be developed much more easily. -1 from me. Features are also documented by people using them, not just by the devs. We like to say that you can contribute to open source projects not just by coding, but if we do that, I don't think we are going to get many contributions from users, leaving the documentation to be written only by developers. I try to keep the Processing documentation up to date, but only documenting the interface itself and the framework, not the algorithms. That's the reason why a large part of algorithms in Processing are not documented. Fortunately, some users have contributed documentation, and they have added descriptions of several algorithms, but the have done that *after* using the (hitherto undocumented) algorithm and becoming familiar with it. No one is going to document something that he cannot use yet. Let's encourage developers to commit
Re: [Qgis-developer] [Qgis-user] Stress about release plans
I think stubs from github to the visual changelog would be great. Also, it would be great if the visual changelog could some day be hosted under a qgis.org address. The visual changelog is very useful and I always point users to it after a new version was released. It looks a bit strange if the address is not on the qgis.org domain. Andreas Am 23.07.2014 07:43, schrieb Nathan Woodrow: We could make a script to just pull out everything with [FEATURE] in the commit between a date range if that will help. Maybe we could create stubs in Tims changelog system using something like this. - Nathan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [Qgis-user] Stress about release plans
+1 2014-07-23 10:18 GMT+02:00 Andreas Neumann a.neum...@carto.net: Also, it would be great if the visual changelog could some day be hosted under a qgis.org address. The visual changelog is very useful and I always point users to it after a new version was released. It looks a bit strange if the address is not on the qgis.org domain. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Working with the new Legend
Hi again On Fri, Jun 27, 2014 at 11:20 PM, Gary Sherman gsher...@geoapt.com wrote: Having read the thread about the new legend merge, I'm wondering if there is a summary on how to work with it via Python. Here's first post introducing the new API - more will follow... http://www.lutraconsulting.co.uk/blog/2014/07/06/qgis-layer-tree-api-part-1/ Later I will try to update also the cookbook. Cheers Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] no zebra frame in print composer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I'm working with the master version and I discovered the new awesome feature of multiple grids in the print composer! Really amazing! I'm also facing a problem: I'm not able to draw the zebra frame anymore. I select it from the drop-down menu but nothing appears in the map canvas. Should I open a ticket? Cheers Matteo -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTz3kMAAoJEBy7UYf0gaEOwXkIAIbDsLkGZMUN7cKQB9/R0EQ9 z9xxKpiTmU9Wn+3ONGiFUmCDJl64CAGBqr3Lcqlrz/pqWbIL12mgwiz7zA8ZZfrg L9n1UGDbcyzOSSC7O4K0GxjEhZdiDdzI5yVJ1pAGsNyLOZy8Ie+4E9tnZ+Qme7An F81UpKm90KMXBUvQaEZBQncpC4LPgr2qCP10GXniyPpSXXWk7Y0ptnLwIeNLgy66 jsqhUKXROOQK/uK9vvXnNV5NN3F/E2McarXxMc5Ez94H4lJNNwFz5jMX85LJy446 Cy4+UGmAZF3kxzi8PNn2o3tcwWdNF0CUMY9ARLl6zQuQ5410R46xPhAZQAmOoLk= =0fMs -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] attribute table row cache
Hi, the option Attribute table row cache under settings - options - data sources makes it possible to save the last loaded N attribute rows so that working with the attribute table will be quicker. The cache will be deleted when closing the attribute table. What is the maximum number of lines here and what happens, if I set it to 0 - would that cache all line or no lines? I would like to load the complete attribute table from an external database into the cache. Is that option possible? Thanks Otto ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] attribute table row cache
Hi Otto, Currently you will need to set a number large enough to hold all your records. It would be a very simple fix to switch to the (quite sensible) operation mode you describe (0: cache all). Would it be possible for you to test a pull request/branch if I create one? Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] attribute table row cache
Am Wed, 23 Jul 2014 12:45:37 +0200 schrieb Matthias Kuhn matthias.k...@gmx.ch: Hi Otto, Currently you will need to set a number large enough to hold all your records. It would be a very simple fix to switch to the (quite sensible) operation mode you describe (0: cache all). Would it be possible for you to test a pull request/branch if I create one? Matthias sure, I can do that. Regards, Otto ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] QGIS Browser crashes in (re)selection
Hi, at least in nightly 2.5 win x64 (latest) QGIS Browser crashes when; - layer selected, looked metadata etc - some directory selected - the same original layer selected - crash Hmm, also openSuse linux 2.4 latest does the same. Following messages on terminal: ERROR 4: Unable to open /home/kari/OpenMaps/Helsinki_avoin/Metsat/Helsinkirajaukset.shp or /home/kari/OpenMaps/Helsinki_avoin/Metsat/Helsinkirajaukset.SHP. Object::disconnect: No such signal QgsAttributeTableFilterModel::filterAboutToBeInvalidated() Object::disconnect: (receiver name: 'attributeTable') Object::disconnect: No such signal QgsAttributeTableFilterModel::filterInvalidated() Object::disconnect: (receiver name: 'attributeTable') ERROR 4: Unable to open /home/kari/OpenMaps/Helsinki_avoin/Metsat/Helsinkirajaukset.shp or /home/kari/OpenMaps/Helsinki_avoin/Metsat/Helsinkirajaukset.SHP. Segmentation fault Funny thing that it opens Helsinkirajaukset.shp nicely shows metadata, preview and attributes (1. ERROR 4) and next/second ERROR 4 crash. Cheers, Kari -- Kari Salovaara Hanko, Finland Volunteers do not necessarily have the time; they just have the heart. ~ Elizabeth Andrew ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Project temp file archive bit.
The behavior of the project temp file has changed with 2.4. The archive bit is being set. Could you please turn the archive bit off? ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis compile with xcode 5.1.1 (qgis2.5.0.xcodeproj can not be opened Because the project file cannot be parsed.)
I didn't have much luck with generated Xcode project files way back before I overhauled the cmake configuration. You're better off making it by hand (I did that for a while, but it was a pain to maintain). Or just use the build instructions and do it all in the Terminal. Cmake has probably improved its xcode generator, but QGIS is a complex project and I still wouldn't trust cmake to get it right. On Jul 22, 2014, at 10:59 PM, otmane yazidi alaoui yazidiotm...@gmail.com wrote: • Hit the Configure button near the bottom of the window. • Pick 'XCode' as the generator and choose to use the native compilers. • Answer Ok when asked if you want to create the build directory. • Wait for the configure process to finish • The screen will now have several configuration options on it, which will be red. You don't need to change their value. Just click the Configure button again. • The options will turn grey, and the Generate button at the bottom will now be enabled. Click Generate. • The build files will now be generated in the location you picked. but the open file create, I get this error: qgis2.5.0.xcodeproj can not be opened Because the project file cannot be parsed. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer - William Kyngesburye kyngchaos*at*kyngchaos*dot*com http://www.kyngchaos.com/ Earth: Mostly harmless - revised entry in the HitchHiker's Guide to the Galaxy ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] qgis compile with xcode 5.1.1 (qgis2.5.0.xcodeproj can not be opened Because the project file cannot be parsed.)
Hi, If you are feeling adventurous, you can try a new methodology for setting up a development environment on Mac [0]. It utilizes the Homebrew package manager, and requires no manual compiling, and many pre-compiled binaries (if everything goes smoothly). Please post any issues to the tap's tracker [1]. [0] https://github.com/OSGeo/homebrew-osgeo4mac/wiki/Developing-on-QGIS-using-OSGeo4Mac [1] https://github.com/OSGeo/homebrew-osgeo4mac/issues Regards, Larry Shaffer Dakota Cartography Black Hills, South Dakota On Tue, Jul 22, 2014 at 9:59 PM, otmane yazidi alaoui yazidiotm...@gmail.com wrote: 1. Hit the *Configure* button near the bottom of the window. 2. Pick 'XCode' as the generator and choose to use the native compilers. 3. Answer *Ok* when asked if you want to create the build directory. 4. Wait for the configure process to finish 5. The screen will now have several configuration options on it, which will be red. You don't need to change their value. Just click the *Configure* button again. 6. The options will turn grey, and the *Generate* button at the bottom will now be enabled. Click *Generate*. 7. The build files will now be generated in the location you picked. but the open file create, I get this error: qgis2.5.0.xcodeproj can not be opened Because the project file cannot be parsed. ___ 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] setFilterExpression() does not works?
Hi all, seems expression filtering of features does not works when used from Python. Here is my test code for Python console: layer = iface.mapCanvas().currentLayer() expr = 'dt = \'2014-07-05\' AND abs(y - 3.0) = 0.01' request = QgsFeatureRequest().setFilterExpression(expr) for f in layer.getFeatures(request): print 'found' This code find no matches in attached shapefile when executed from Python console, but when I try to use same expression in Select by Expression tool it selects one feature. Maybe I miss something? Should I open a ticket? -- Alexander Bruy test.tar.bz2 Description: BZip2 compressed data ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] compile error
Hi, Jürgen or Nathan - can you please disable the sip parts for now, as discussed - as currently I can't compile master on Ubuntu. Maybe we can re-introduce it once the Debian/Ubuntu issues around qscintilla and sip are resolved. This would be much appreciated! Thanks, Andreas Am 22.07.2014 14:18, schrieb Nathan Woodrow: Hey Jurgen, We can disable the sip parts for the code editors for now if it is causing issues. They are really only light wrappers around some QScintilla code. - Nathan On Tue, Jul 22, 2014 at 10:06 PM, Jürgen E. j...@norbit.de mailto:j...@norbit.de wrote: Hi Andreas, On Tue, 22. Jul 2014 at 11:53:14 +, Andreas Neumann wrote: same problem here. qscimod4.sip is not available on my machine and I don't know which ubuntu package would contain this file. That's a debian bug (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=755491) The sip files are not currently packaged. As a workaround I included them in QGIS [8f0b8987 7e815cad] - but only the latest version (in debian) - which could have worked for older ones as well, if Qscintillas API was stable enough. Apparently it isn't. The nightly builds failed with precise already - saucy and trust worked however, but that's as far as it got as of now. I'll check what else I can do, once I now which other distributions are affected. 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 -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ 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 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] setFilterExpression() does not works?
Hi Alexander, This seems to be related to the copy constructor of QgsExpression not working properly. Please file a bug for this. It's a quite complex topic, because the original expression string cannot just be used because of dynamically created expressions. On the other hand the dynamic method fails for certain types (longlong I think). And personally I think that QgsExpressions could be implicitly shared, but I've heard other opinions on this topic. Cheers, Matthias On 23.07.2014 16:16, Alexander Bruy wrote: Hi all, seems expression filtering of features does not works when used from Python. Here is my test code for Python console: layer = iface.mapCanvas().currentLayer() expr = 'dt = \'2014-07-05\' AND abs(y - 3.0) = 0.01' request = QgsFeatureRequest().setFilterExpression(expr) for f in layer.getFeatures(request): print 'found' This code find no matches in attached shapefile when executed from Python console, but when I try to use same expression in Select by Expression tool it selects one feature. Maybe I miss something? Should I open a ticket? ___ 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] setFilterExpression() does not works?
Hi Matthias, thanks for your reply. Ticket opened https://hub.qgis.org/issues/10936 2014-07-23 18:28 GMT+03:00 Matthias Kuhn matthias.k...@gmx.ch: Hi Alexander, This seems to be related to the copy constructor of QgsExpression not working properly. Please file a bug for this. It's a quite complex topic, because the original expression string cannot just be used because of dynamically created expressions. On the other hand the dynamic method fails for certain types (longlong I think). And personally I think that QgsExpressions could be implicitly shared, but I've heard other opinions on this topic. Cheers, Matthias On 23.07.2014 16:16, Alexander Bruy wrote: Hi all, seems expression filtering of features does not works when used from Python. Here is my test code for Python console: layer = iface.mapCanvas().currentLayer() expr = 'dt = \'2014-07-05\' AND abs(y - 3.0) = 0.01' request = QgsFeatureRequest().setFilterExpression(expr) for f in layer.getFeatures(request): print 'found' This code find no matches in attached shapefile when executed from Python console, but when I try to use same expression in Select by Expression tool it selects one feature. Maybe I miss something? Should I open a ticket? ___ 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] Project temp file archive bit.
For some reason a project temp file or a backup file using the extension .qgs~ is showing up in my projects directory with QGIS 2.4 Win 7 64 bit. The xcopy *.qgs command I use for archival purposes is catching the .qgs~ file as well. This behavior is different from every QGIS version up to at least 2.18 that I have used, for at least the last 5 years. Why has this changed? Could it be put back like it was? Does anybody have a workaround? Is there a switch somewhere to put the temp file in another subdirectory (I did a casual search for this but couldn't find one)? On 7/23/2014 7:46 AM, G. Garibaldi wrote: The behavior of the project temp file has changed with 2.4. The archive bit is being set. Could you please turn the archive bit off? ___ 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] Project temp file archive bit.
Hi G, On Wed, 23. Jul 2014 at 12:20:56 -0500, G. Garibaldi wrote: For some reason a project temp file or a backup file using the extension .qgs~ is showing up in my projects directory with QGIS 2.4 Win 7 64 bit. It's not a temp file. It's backup of version of the project file (or better put the renamed original). The xcopy *.qgs command I use for archival purposes is catching the .qgs~ file as well. This behavior is different from every QGIS version up to at least 2.18 that I have used, for at least the last 5 years. Why has this changed? We are still at 2.4 and the backup file was introduced in November 2013. Could it be put back like it was? Does anybody have a workaround? Is there a switch somewhere to put the temp file in another subdirectory (I did a casual search for this but couldn't find one)? What's the problem with having a second backup copy? 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 -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Project temp file archive bit.
Every day I increment the Julian date on the project file I work on. So MyIncredibleProject.qgs file becomes, for example today's Julian calendar date, 203MyIncredibleProject.qgs. Tomorrow the first thing I do will be to increment the file to 204MyIncredibleProject.qgs and so on. Each day I archive the previous day's file to DVD. On January 1st, 2015 I will start a new DVD and file the 2014 data away. Such an elaborate backup scheme became necessary in my case due to the complexity of my project which involves dozens of layers of varying data types and the regular trashing of the project file by QGIS. An option to do away with the automatic backup file would be nice. I'll take it from there. I'm a big boy, I can tie my own shoelaces. I am very happy with 2.4. On 7/23/2014 2:23 PM, Jürgen E. Fischer wrote: Hi G, On Wed, 23. Jul 2014 at 12:20:56 -0500, G. Garibaldi wrote: For some reason a project temp file or a backup file using the extension .qgs~ is showing up in my projects directory with QGIS 2.4 Win 7 64 bit. It's not a temp file. It's backup of version of the project file (or better put the renamed original). The xcopy *.qgs command I use for archival purposes is catching the .qgs~ file as well. This behavior is different from every QGIS version up to at least 2.18 that I have used, for at least the last 5 years. Why has this changed? We are still at 2.4 and the backup file was introduced in November 2013. Could it be put back like it was? Does anybody have a workaround? Is there a switch somewhere to put the temp file in another subdirectory (I did a casual search for this but couldn't find one)? What's the problem with having a second backup copy? Jürgen ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Project temp file archive bit.
If this was me I would store you project file in a git repo and just commit every day, or after every change, and backup the git repo. I have done this in the past and it has served me well. Just adding dates to the end of a file is a very old school way of doing backups. In any case I don't think adding an option for it is a smart idea. It is there for a reason I'm sure you can work around it from your script end. Make sure you look at the exclue: arg for xcopy you should be able to add *,qgs~ to it so it will ignore those. - Nathan On Thu, Jul 24, 2014 at 6:45 AM, G. Garibaldi digitalm...@cox.net wrote: Every day I increment the Julian date on the project file I work on. So MyIncredibleProject.qgs file becomes, for example today's Julian calendar date, 203MyIncredibleProject.qgs. Tomorrow the first thing I do will be to increment the file to 204MyIncredibleProject.qgs and so on. Each day I archive the previous day's file to DVD. On January 1st, 2015 I will start a new DVD and file the 2014 data away. Such an elaborate backup scheme became necessary in my case due to the complexity of my project which involves dozens of layers of varying data types and the regular trashing of the project file by QGIS. An option to do away with the automatic backup file would be nice. I'll take it from there. I'm a big boy, I can tie my own shoelaces. I am very happy with 2.4. On 7/23/2014 2:23 PM, Jürgen E. Fischer wrote: Hi G, On Wed, 23. Jul 2014 at 12:20:56 -0500, G. Garibaldi wrote: For some reason a project temp file or a backup file using the extension .qgs~ is showing up in my projects directory with QGIS 2.4 Win 7 64 bit. It's not a temp file. It's backup of version of the project file (or better put the renamed original). The xcopy *.qgs command I use for archival purposes is catching the .qgs~ file as well. This behavior is different from every QGIS version up to at least 2.18 that I have used, for at least the last 5 years. Why has this changed? We are still at 2.4 and the backup file was introduced in November 2013. Could it be put back like it was? Does anybody have a workaround? Is there a switch somewhere to put the temp file in another subdirectory (I did a casual search for this but couldn't find one)? What's the problem with having a second backup copy? 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] Project temp file archive bit.
On 7/23/2014 4:52 PM, Nathan Woodrow wrote: If this was me I would store you project file in a git repo and just commit every day, or after every change, and backup the git repo. I have done this in the past and it has served me well. Just adding dates to the end of a file is a very old school way of doing backups. Confirmed. In any case I don't think adding an option for it is a smart idea. It is there for a reason I'm sure you can work around it from your script end. Make sure you look at the exclue: arg for xcopy you should be able to add *,qgs~ to it so it will ignore those. Yep. I feel old. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Project temp file archive bit.
Hi Jürgen On 23.07.2014 21:23, Jürgen E. Fischer wrote: Hi G, On Wed, 23. Jul 2014 at 12:20:56 -0500, G. Garibaldi wrote: For some reason a project temp file or a backup file using the extension .qgs~ is showing up in my projects directory with QGIS 2.4 Win 7 64 bit. It's not a temp file. It's backup of version of the project file (or better put the renamed original). What is the purpose of this file? When is it produced and does QGIS revert to this copy under certain circumstances? Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Project temp file archive bit.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi On 23/07/2014 23:56, Matthias Kuhn wrote: Hi Jürgen On 23.07.2014 21:23, Jürgen E. Fischer wrote: Hi G, On Wed, 23. Jul 2014 at 12:20:56 -0500, G. Garibaldi wrote: For some reason a project temp file or a backup file using the extension .qgs~ is showing up in my projects directory with QGIS 2.4 Win 7 64 bit. It's not a temp file. It's backup of version of the project file (or better put the renamed original). What is the purpose of this file? When is it produced and does QGIS revert to this copy under certain circumstances? Speaking for Juergen, I believe it is written with the previous saved state of the project file each time you press save. So if you save and the project file gets corrupted (its happened to me a few times in the past) you can fallback to the last known good state. Regards Tim Matthias ___ 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/ iEYEARECAAYFAlPQMR4ACgkQqk07qZdiYjeK7ACfesLPTp+GoIecJ2LcXD2wc+ZH hOwAoLgy/P+W5+8KZQVZgavUdF707wdf =cCrh -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] Project temp file archive bit.
Hi Tim, On Don 24 Jul 2014 00:03:10 CEST, Tim Sutton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi On 23/07/2014 23:56, Matthias Kuhn wrote: Hi Jürgen On 23.07.2014 21:23, Jürgen E. Fischer wrote: Hi G, On Wed, 23. Jul 2014 at 12:20:56 -0500, G. Garibaldi wrote: For some reason a project temp file or a backup file using the extension .qgs~ is showing up in my projects directory with QGIS 2.4 Win 7 64 bit. It's not a temp file. It's backup of version of the project file (or better put the renamed original). What is the purpose of this file? When is it produced and does QGIS revert to this copy under certain circumstances? Speaking for Juergen, I believe it is written with the previous saved state of the project file each time you press save. So if you save and the project file gets corrupted (its happened to me a few times in the past) you can fallback to the last known good state. In this case wouldn't it be better to write to a temp file when saving (.qgs~) and after successfully having written this file rename it to the real name (.qgs)? This way there would be no garbage and a user does not need to know about cryptic file renames. Regards Matthias ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Project temp file archive bit.
Hi Matthias, On Wed, 23. Jul 2014 at 23:56:43 +0200, Matthias Kuhn wrote: What is the purpose of this file? Having a backup when the project file got silently corrupted or truncated and can't be loaded again. Which does/used to happen sometimes for unknown reasons. When is it produced Everytime the project file is saved. and does QGIS revert to this copy under certain circumstances? No. 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 -- norBIT Gesellschaft fuer Unternehmensberatung und Informationssysteme mbH Rheinstrasse 13, 26506 Norden GF: Jelto Buurman, HR: Amtsgericht Emden, HRB 5502 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] GSOC Weekly Report 9: Schematization Plug-in for QGIS
Hi everyone, *Weekly Report 9* *What was done this week?* - I discussed with my mentors the way to go about handling the inaccuracies/errors in the approach. - This is being done by adding a checking mechanism in the code so that specific type of inaccuracies which were encountered will be handled. *What is the plan for next week?* - Will try to complete the implementation of this checking mechanism in the coming week. *Wiki page : *http://hub.qgis.org/wiki/quantum-gis/nishithm *Code repository :* https://github.com/nishithm/schematization Thanks and regards, Nishith Maheshwari Lab for Spatial Informatics IIIT Hyderabad ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] cmake configure error
Hi I'm getting a cmake error on master: Touch support disabled CMake Error at cmake/FindQScintilla.cmake:58 (FILE): file Internal CMake error when trying to open file: /usr/include/qt4/Qsci/Qsci/qsciglobal.h for reading. Call Stack (most recent call first): CMakeLists.txt:259 (FIND_PACKAGE) Found QScintilla2: /usr/lib/libqscintilla2.so () Qsci seems to be repeated in /usr/include/qt4/Qsci/Qsci/qsciglobal.h. It works if I remove one Qsci. Regards Stefan Freundliche Grüsse Stefan Ziegler Kantonsgeometer Amt für Geoinformation Amtliche Vermessung Rötistrasse 4 4500 Solothurn Telefon +41 32 627 75 96 Telefax +41 32 627 75 98 stefan.zieg...@bd.so.ch http://www.so.ch ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Plugin howto
Hi all. Many plugin developers do not know how to move their plugin under the appropriate menu: can someone point us to the relevant cookbook page, or other instructions? All the best, and 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
