Re: [Qgis-developer] Post-release period of portable commits only?
Nightly builds (or weekly snapshots for that matter) are very different
from a publicized, pre-release preview build. With a prepared pre-release
preview, users are at least expecting that basic functioning will work,
that's something the nightly builds simply can't guarantee by the nature
of what those are. Very few average user will install a nightly development
build, but you get an higher chance of getting a broader number of people
(that interacts with QGIS in different ways) to test out your product
before it's released.
It also helps channel what your describing as noise (i.e. users running
into problems) into a better managed call for people to test and report.
The noise will happen no matter what. But it might make some sense to
trigger some of that noise (valid bugs and invalid RTFM cases) _before_
you release your final version via a pre-release social media and news site
try this pre-release build :)
It's really more a matter of presentation to the users than of actual work.
As you point out Jef, you guys already have the infrastructure that
produces weekly standalone builds, and daily packages.
Math
On Mon, Feb 24, 2014 at 2:40 PM, Jürgen E. j...@norbit.de wrote:
Hi Mathieu,
On Mon, 24. Feb 2014 at 09:17:11 +0700, Mathieu Pellerin wrote:
That reminds me of someone mentioning in a ticket of a 2.0 issue resolved
against qgis 2.1 that he'd wait (angrily?) having fix backported into a
(mythical) 2.0.x update rather than him moving to 2.2 and having to deal
with possible regressions. I was thinking at the time that this sounds to
me like a flawed behavior by some QGIS users, an egg or chicken
situation.
How are regressions fixed if users are not doing their parts in
uncovering
and reporting them.
That led me to think there might be a very low-cost, high reward behavior
QGIS could adopt: 4, or 2, weeks before the release date, {beta,release
candidate,tech preview,etc.} builds (from master, no need to branch out
really) are pushed out to osgeo4w linux and quite loudly advertised
(blog
posts, social media, etc.) to get as many users as possible to test drive
it. The users' feedback would enrich the 4-weeks period when developers
are
to be focused on bug-fixing only.
Thoughts? Was that already suggested and declined?
What's the difference to the nightly builds and the weekly standalone
snapshot
for Windows - except for the noise of course?
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50
Software Engineer D-26506 Norden
http://www.norbit.de
QGIS PSC member (RM) Germany IRC: 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 mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
-but you get an higher chance of getting a broader number of people (that
interacts with QGIS in different ways) to test out your product before it's
released.
+but you get an higher chance of getting a broader number of people (that
interacts with QGIS in different ways) to test out your product before it's
released *with an official beta/preview build*.
:)
On Mon, Feb 24, 2014 at 3:42 PM, Mathieu Pellerin nirvn.a...@gmail.comwrote:
Nightly builds (or weekly snapshots for that matter) are very different
from a publicized, pre-release preview build. With a prepared pre-release
preview, users are at least expecting that basic functioning will work,
that's something the nightly builds simply can't guarantee by the nature
of what those are. Very few average user will install a nightly development
build, but you get an higher chance of getting a broader number of people
(that interacts with QGIS in different ways) to test out your product
before it's released.
It also helps channel what your describing as noise (i.e. users running
into problems) into a better managed call for people to test and report.
The noise will happen no matter what. But it might make some sense to
trigger some of that noise (valid bugs and invalid RTFM cases) _before_
you release your final version via a pre-release social media and news site
try this pre-release build :)
It's really more a matter of presentation to the users than of actual
work. As you point out Jef, you guys already have the infrastructure that
produces weekly standalone builds, and daily packages.
Math
On Mon, Feb 24, 2014 at 2:40 PM, Jürgen E. j...@norbit.de wrote:
Hi Mathieu,
On Mon, 24. Feb 2014 at 09:17:11 +0700, Mathieu Pellerin wrote:
That reminds me of someone mentioning in a ticket of a 2.0 issue
resolved
against qgis 2.1 that he'd wait (angrily?) having fix backported into a
(mythical) 2.0.x update rather than him moving to 2.2 and having to deal
with possible regressions. I was thinking at the time that this sounds
to
me like a flawed behavior by some QGIS users, an egg or chicken
situation.
How are regressions fixed if users are not doing their parts in
uncovering
and reporting them.
That led me to think there might be a very low-cost, high reward
behavior
QGIS could adopt: 4, or 2, weeks before the release date, {beta,release
candidate,tech preview,etc.} builds (from master, no need to branch out
really) are pushed out to osgeo4w linux and quite loudly advertised
(blog
posts, social media, etc.) to get as many users as possible to test
drive
it. The users' feedback would enrich the 4-weeks period when developers
are
to be focused on bug-fixing only.
Thoughts? Was that already suggested and declined?
What's the difference to the nightly builds and the weekly standalone
snapshot
for Windows - except for the noise of course?
Jürgen
--
Jürgen E. Fischer norBIT GmbH Tel.
+49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13Fax.
+49-4931-918175-50
Software Engineer D-26506 Norden
http://www.norbit.de
QGIS PSC member (RM) Germany IRC: 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 mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released
Hi Tom, I see you started collecting Meta Data Catalogues (at least on national scale) for the default services in the plugin. I like the idea very much. What about asking (QGIS) users explicitly to provide addresses for their countries? Such a collection would be really valuable (especially for people working across borders) and maybe also of interest for other projects as there are already comparable initiatives on collecting information on available data: http://wiki.osgeo.org/wiki/Geodata_Discovery_Working_Group http://grasswiki.osgeo.org/wiki/Global_datasets What do you think? Cheers, Stefan -Original Message- From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom Kralidis Sent: 19. februar 2014 13:00 To: Blumentrath, Stefan Cc: qgis-developer@lists.osgeo.org Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released Hi Stefan: thanks for the info. This is the dreaded metadata link types issue. If possible, can you open an issue on this so we can discuss this in the ticket? Thanks ..Tom On Wed, 19 Feb 2014, Blumentrath, Stefan wrote: Date: Wed, 19 Feb 2014 11:54:04 + From: Blumentrath, Stefan stefan.blumentr...@nina.no To: Tom Kralidis tomkrali...@gmail.com Cc: qgis-developer@lists.osgeo.org qgis-developer@lists.osgeo.org Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released Done. BTW, the problem that I could not add WMS / WFS is likely to be on the CSW side and not the client side, cause it worked for some WMS... I was using the CSW for official map data in Norway provided by geonorge: http://www.geonorge.no/geonetwork/srv/no/csw? There are several / many WMS listed which cannot be added... Would you mind double checking if this is a server-side problem? Cheers Stefan -Original Message- From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom Kralidis Sent: 19. februar 2014 12:32 To: Blumentrath, Stefan Cc: qgis-developer@lists.osgeo.org Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released Hi Stefan: thanks for the info/kind words. Yes, can you file a ticket at https://github.com/geopython/MetaSearch/issues/new with the steps taken, so we can reproduce and fix the issue. Thanks ..Tom On Wed, 19 Feb 2014, Blumentrath, Stefan wrote: Date: Wed, 19 Feb 2014 08:06:59 + From: Blumentrath, Stefan stefan.blumentr...@nina.no To: Tom Kralidis tomkrali...@gmail.com, qgis-developer@lists.osgeo.org qgis-developer@lists.osgeo.org Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released Hi Tom, Thank you (and your team) very much for this excellent plugin! Very valuable! I tested version 0.1.1 (in QGIS 2.0.1 on Win7) and love it already. Adding WMS/WCS/WFS however does not seem to be active yet, and using the back arrows throws an error: Traceback (most recent call last): File C:\Users\ninsbl/.qgis2/python/plugins\MetaSearch\dialogs\maindialog.py, line 572, in navigate if res == QMessageBox.Ok: UnboundLocalError: local variable 'res' referenced before assignment Should I file a ticket? Still the plugin is already very useful and personally I think it should make it to QGIS core in the long run! So, thanks again, Stefan -Original Message- From: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Tom Kralidis Sent: 18. februar 2014 21:16 To: qgis-developer@lists.osgeo.org Subject: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released The MetaSearch team announces the release of MetaSearch 0.1.0. The 0.1.0 release marks the initial offering of a CSW client for QGIS 2, with significant features to enable plug and play interoperability with OGC CSW services. - find and bind functionality allowing users to discover and add layers from WMS, WFS, WCS, or WMTS services dynamically to the map - template-based service and record metadata view, allowing for custom templating of responses - visual footprint of CSW results - display of all metadata access links, allowing users to click/download data to add to QGIS - spatial and aspatial querying of CSW services Version 0.1.0 represents a significant engineering effort to bring CSW support for QGIS 2, make the codebase sustainable/extensible and easy for developers and documentation teams to make contributions. Longer term plans include: - supporting other catalog APIs (CKAN, etc.) - making MetaSearch part of QGIS core - transifex localization - display thumbnail/browse images We are looking for feedback and testers for the plugin. Comments, bugs, features/enhancements are welcome (IRC, GitHub issue tracker, etc.). The full list of enhancements and bug fixes is available at https://github.com/geopython/MetaSearch/issues?milestone=1page=1sta t e=closed The plugin is available from the QGIS Plugins Repository
Re: [Qgis-developer] Multi-threading rendering merged to master
Hi Mathieu On Mon, Feb 24, 2014 at 9:52 AM, Mathieu Pellerin nirvn.a...@gmail.com wrote: Martin, Fantastic work; I knew to expect a better rendering experience, yet I was caught by surprise at how much of a positive difference it makes. Few things from my 10-minutes play with it: * The map overview extend is broken, its extend goes way, way beyond the extend of the sum of all the layers in a given project In my quick test everything seems to work fine, I will need more details about the issue - feel free to file a bug report. * The 'xxx' option doesn't seem to be taken into consideration, the parallel rendering is always activated on my machine irrespective of whether I checked the box or not. Works fine for me... but there are two different concepts: 1. rendering in background - GUI is responsive even while the map is being rendered - this is always on 2. parallel vs sequential rendering - in sequential mode, there is just one job that renders everything - in parallel mode, the job is split into several jobs (one job per map layer) and jobs can therefore use multiple cores Are you sure you are not referring to point 1? Also, it is worth noting that parallel rendering may bring improvements only when there is more than one layer to render. * Half of the times I exited QGIS, the application process was not terminating and this error message was thrown: *** Error in `/home/webmaster/apps/bin/qgis': corrupted double-linked list: 0x0a0680f0 ***; I had to manually kill the process I had this problem too - due to some garbage in the build directory (incompatible plugin DLLs). Try to run QGIS with --noplugins option. But better do a clean build. Regards Martin ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
Hi Mathieu, On Mon, 24. Feb 2014 at 15:42:19 +0700, Mathieu Pellerin wrote: Nightly builds (or weekly snapshots for that matter) are very different from a publicized, pre-release preview build. With a prepared pre-release preview, users are at least expecting that basic functioning will work, that's something the nightly builds simply can't guarantee by the nature of what those are. Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? Very few average user will install a nightly development build, but you get an higher chance of getting a broader number of people (that interacts with QGIS in different ways) to test out your product before it's released. Why should it matter if we call it weekly snapshot, nightly build or prerelease? It's the same thing, just the tag is different. And installation is essential as easy as installing the stable release. It also helps channel what your describing as noise (i.e. users running into problems) into a better managed call for people to test and report. The noise will happen no matter what. But it might make some sense to trigger some of that noise (valid bugs and invalid RTFM cases) _before_ you release your final version via a pre-release social media and news site try this pre-release build :) It's really more a matter of presentation to the users than of actual work. Exactly. And that's what I meant with noise: tada, there's a new weekly snapshot/prerelease/nightly build - not users running into problems. Because I see that as the only significant difference to what we already have. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: 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] Datum transformations
Hi Martin if some code in QGIS creates coordinate transform without using transform provided by map renderer, it will be created without the chosen datum transform and will therefore provide incorrect results There is a lot of code and plugins that rely on the assumption that a coordinate transformation is fully defined by source crs and destination crs. I agree it is not an ideal situation, however that assumption is simply not correct and it probably takes some time until all places are changed. I remember having changed that for QgsVectorFileWriter, but other places (e.g. measuring tool) still behaves not correct. I guess there is still a question what to do in cases when there are more layers with the same CRS but with different datum transforms - I am not sure how well the current implementation handles that case (if there is a datum transform defined in options, it will be used for all layers with given CRS) This is my main concern regarding caching of datum transformation. It is very important to have the possibility to control the datum transformation for each layer individually. E.g. it is quite common to load a layer twice with different datum transformations to see the difference. This was actually my main visual test during implementation, so I'm quite sure it works in 2.2 (or at least it was when I tested that last time). In case a user defines a default transformation, he accepts that it will be silently used for all layers (and there is still the possibility to delete that in options). - GUI: have a tab in project properties where non-default datum transforms would be managed - instead of requiring the user to select the datum transform immediately when the layer was added (and without being able to change the decision later) I don't have a strong opinion if it should be in project properties or if the user should be asked immediately. The immediate selection has been implemented following the behaviour of a commercial GIS. However, the possibility to change it later easily does also sound good to me. Btw., congratulations to the merge of the multithreading branch! Regards, Marco On 24.02.2014 06:03, Martin Dobias wrote: Hi (Marco) I have some suggestions for the implementation of datum transforms in QGIS and I would like to hear your opinion about them. In the 2.2 release, as far as I understand the logic is implemented like this: - map renderer emits a signal asking for datum transform choice - map canvas catches the signal and provides either the default (defined in options) or asks the user in a dialog - and sends this information back to map renderer - map renderer stores the information about datum transforms and does loading/saving in project file - map renderer provides access to coordinate transforms (with correct datum transform info) The main issue I see here is the fact that in case of non-default datum transforms - if some code in QGIS creates coordinate transform without using transform provided by map renderer, it will be created without the chosen datum transform and will therefore provide incorrect results. This can lead to subtle bugs (for example, QgsVectorFileWriter will not use the defined datum transforms, causing offsets in reprojected data). Changing all the possible places where coordinate transform may be used to call QgsMapRenderer::transformation() seems impractical. What do you think about: - using QgsCoordinateTransformCache internally by QgsCoordinateTransform anytime a new transform should be instantiated - keeping the datum transform information in a helper class (loaded/saved by project) and using it directly by QgsCoordinateTransform - so any QGIS code will use the correct datum transform - GUI: have a tab in project properties where non-default datum transforms would be managed - instead of requiring the user to select the datum transform immediately when the layer was added (and without being able to change the decision later) Currently the datum transforms do not work at all in master after the merge of MTR because the QgsMapRenderer class is not used for rendering anymore. Before trying to do anything in that area I would like to hear your input. I guess there is still a question what to do in cases when there are more layers with the same CRS but with different datum transforms - I am not sure how well the current implementation handles that case (if there is a datum transform defined in options, it will be used for all layers with given CRS) and how much we need such functionality. Regards Martin -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Which compiler for a c++ QGIS custom app
Hi Jürgen, On 21 Feb 2014, at 16:24, Jürgen E. Fischer j...@norbit.de wrote: But QGIS and Qt in OSGeo4W is built with Visual C++ not MinGW. You can't use OSGeo4W's Qt with MinGW. I installed Visual Studio Express 2013, and it seems the compiler given with (version 12.0) is not compliant with Qt libs from the osgeo package. Do you know if I should I restrict to a given version of the compiler? Which one has been used for building osgeo’s qt lib? I saw that Nathan is using version 9.0. Thanks a lot, Denis___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Which compiler for a c++ QGIS custom app
The supported version is VS 2008. I have never tried building with anything else. - Nathan On Mon, Feb 24, 2014 at 9:10 PM, Rouzaud Denis denis.rouz...@gmail.comwrote: Hi Jürgen, On 21 Feb 2014, at 16:24, Jürgen E. Fischer j...@norbit.de wrote: But QGIS and Qt in OSGeo4W is built with Visual C++ not MinGW. You can't use OSGeo4W's Qt with MinGW. I installed Visual Studio Express 2013, and it seems the compiler given with (version 12.0) is not compliant with Qt libs from the osgeo package. Do you know if I should I restrict to a given version of the compiler? Which one has been used for building osgeo's qt lib? I saw that Nathan is using version 9.0. Thanks a lot, Denis ___ 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] Which compiler for a c++ QGIS custom app
Hi Denis, On Mon, 24. Feb 2014 at 12:10:53 +0100, Rouzaud Denis wrote: I installed Visual Studio Express 2013, and it seems the compiler given with (version 12.0) is not compliant with Qt libs from the osgeo package. Right, if you want to use Qt from OSGeo4W you need to you the same compiler as the one used to build Qt.That is 2008 for 32bit and 2010 for 64bit. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: 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] Which compiler for a c++ QGIS custom app
Thanks a lot Nathan, this brought me further! On 24 Feb 2014, at 12:14, Nathan Woodrow madman...@gmail.com wrote: The supported version is VS 2008. I have never tried building with anything else. - Nathan On Mon, Feb 24, 2014 at 9:10 PM, Rouzaud Denis denis.rouz...@gmail.com wrote: Hi Jürgen, On 21 Feb 2014, at 16:24, Jürgen E. Fischer j...@norbit.de wrote: But QGIS and Qt in OSGeo4W is built with Visual C++ not MinGW. You can't use OSGeo4W's Qt with MinGW. I installed Visual Studio Express 2013, and it seems the compiler given with (version 12.0) is not compliant with Qt libs from the osgeo package. Do you know if I should I restrict to a given version of the compiler? Which one has been used for building osgeo’s qt lib? I saw that Nathan is using version 9.0. Thanks a lot, Denis ___ 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] Processing - bug when editing an open model ?
Hi, I just opened a ticket for this bug : https://hub.qgis.org/issues/9632 2014-02-19 14:54 GMT+01:00 kimaidou kimai...@gmail.com: Hi all, Before reporting a bug, I would like to know if it is not already reported. I am using QGIS 2.0.3 with Processing plugin experimental version 2.0-20131120 (Ubuntu) When I create a graphical model from scratch, everything works fine. I can save the model and run it. But whenever I try to open an existing model, then modify one of the algo and apply modifications with the OK button, the interface freezes completely. I then need to kill QGIS to get out of it which is very bad in case you have not saved the project... Has anyone reported this or should I fill a new bug ? Regards, Michael ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Datum transformations
On 02/24/2014 05:45 PM, Marco Hugentobler wrote: - GUI: have a tab in project properties where non-default datum transforms would be managed - instead of requiring the user to select the datum transform immediately when the layer was added (and without being able to change the decision later) I don't have a strong opinion if it should be in project properties or if the user should be asked immediately. The immediate selection has been implemented following the behaviour of a commercial GIS. However, the possibility to change it later easily does also sound good to me. Btw., congratulations to the merge of the multithreading branch! Regards, Marco Hi Marco, I struggled quite a lot with the interface of a very famous commercial GIS on this issue, I believe there is a real possibility to do better here ! I think it is essential to allow the user to change the transformation later easily, maybe somewhere linked from the CRS choice ? That's where I would go as a user. I was also wondering how you see the relationship between CRS and datum transformation. I use CRSs (all the Beijing54 CRS) which already have a +towgs84 defined in their definition, but several towgs84 coefficients are offered when loading the layer. It is confusing to have to answer that, and if something else than the default coefficients is chosen, the result is incompatible with the proj4 definition. Should we strip these CRS definitions of the towgs84 coefficients (which were only meant for a small area initially, so are not valid everywhere)? Also, do you see a need to allow to define a custom datum transformation, or do you think it is enough that user can create a custom CRS with different towgs84 parameters? Regards, Leyan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] [QGIS Mapserver] is QgsFilter ever used in GetFeatureInfo?
In an old feature request from me [1] I was suggesting to add LIKE/ILIKE filter to GetFeatureInfo FILTER allowed params. Trying to follow the path of the request, it seems that the filter is simply appended to layer subsetstring as it is. QgsFilters' aren't being used, right? giovanni [1] http://hub.qgis.org/issues/6294 -- Giovanni Allegri http://about.me/giovanniallegri Twitter: https://twitter.com/_giohappy_ blog: http://blog.spaziogis.it GEO+ geomatica in Italia http://bit.ly/GEOplus ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Plugin [32] Value Tool approval notification.
Plugin Value Tool approval by etourigny. The plugin version [32] Value Tool 0.8.1 Experimental is now approved Link: http://plugins.qgis.org/plugins/valuetool/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Datum transformations
Hi Leyan I struggled quite a lot with the interface of a very famous commercial GIS on this issue, I believe there is a real possibility to do better here ! I think it is essential to allow the user to change the transformation later easily, maybe somewhere linked from the CRS choice ? That's where I would go as a user. He, he, I bet it is the same GIS :-) I was also wondering how you see the relationship between CRS and datum transformation. I use CRSs (all the Beijing54 CRS) which already have a +towgs84 defined in their definition, but several towgs84 coefficients are offered when loading the layer. It is confusing to have to answer that, and if something else than the default coefficients is chosen, the result is incompatible with the proj4 definition. Should we strip these CRS definitions of the towgs84 coefficients (which were only meant for a small area initially, so are not valid everywhere)? Do you mean we should strip the towgs84 parameters from tbl_srs.parameters or do you mean to deprecate/remove entries from tbl_datum_transform? Also, do you see a need to allow to define a custom datum transformation, or do you think it is enough that user can create a custom CRS with different towgs84 parameters? It is possible to add new entries to tbl_datum_transform to create custom datum transformations. Yes, it would be more convenient to have a gui for that, even if I don't know how often it will be used. You might judge it better since you obviously have to deal often with CRS issues. Regards, Marco On 24.02.2014 13:35, Leyan wrote: On 02/24/2014 05:45 PM, Marco Hugentobler wrote: - GUI: have a tab in project properties where non-default datum transforms would be managed - instead of requiring the user to select the datum transform immediately when the layer was added (and without being able to change the decision later) I don't have a strong opinion if it should be in project properties or if the user should be asked immediately. The immediate selection has been implemented following the behaviour of a commercial GIS. However, the possibility to change it later easily does also sound good to me. Btw., congratulations to the merge of the multithreading branch! Regards, Marco Hi Marco, I struggled quite a lot with the interface of a very famous commercial GIS on this issue, I believe there is a real possibility to do better here ! I think it is essential to allow the user to change the transformation later easily, maybe somewhere linked from the CRS choice ? That's where I would go as a user. I was also wondering how you see the relationship between CRS and datum transformation. I use CRSs (all the Beijing54 CRS) which already have a +towgs84 defined in their definition, but several towgs84 coefficients are offered when loading the layer. It is confusing to have to answer that, and if something else than the default coefficients is chosen, the result is incompatible with the proj4 definition. Should we strip these CRS definitions of the towgs84 coefficients (which were only meant for a small area initially, so are not valid everywhere)? Also, do you see a need to allow to define a custom datum transformation, or do you think it is enough that user can create a custom CRS with different towgs84 parameters? Regards, Leyan ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- Dr. Marco Hugentobler Sourcepole - Linux Open Source Solutions Weberstrasse 5, CH-8004 Zürich, Switzerland marco.hugentob...@sourcepole.ch http://www.sourcepole.ch Technical Advisor QGIS Project Steering Committee ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Datum transformations
On Mon, Feb 24, 2014 at 1:35 PM, Leyan ouyang.leyan...@hotmail.com wrote: On 02/24/2014 05:45 PM, Marco Hugentobler wrote: - GUI: have a tab in project properties where non-default datum transforms would be managed - instead of requiring the user to select the datum transform immediately when the layer was added (and without being able to change the decision later) I don't have a strong opinion if it should be in project properties or if the user should be asked immediately. The immediate selection has been implemented following the behaviour of a commercial GIS. However, the possibility to change it later easily does also sound good to me. Btw., congratulations to the merge of the multithreading branch! Regards, Marco Hi Marco, I struggled quite a lot with the interface of a very famous commercial GIS on this issue, I believe there is a real possibility to do better here ! I think it is essential to allow the user to change the transformation later easily, maybe somewhere linked from the CRS choice ? That's where I would go as a user. I was also wondering how you see the relationship between CRS and datum transformation. I use CRSs (all the Beijing54 CRS) which already have a +towgs84 defined in their definition, but several towgs84 coefficients are offered when loading the layer. It is confusing to have to answer that, and if something else than the default coefficients is chosen, the result is incompatible with the proj4 definition. Should we strip these CRS definitions of the towgs84 coefficients (which were only meant for a small area initially, so are not valid everywhere)? Please note the following related issue: http://hub.qgis.org/issues/9396 deactivate the Select datum transformations dialog by default Maybe the ticket has to be reopened? Best wishes, Anita ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [QGIS Mapserver] is QgsFilter ever used in GetFeatureInfo?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2014 01:45 PM, G. Allegri wrote: In an old feature request from me [1] I was suggesting to add LIKE/ILIKE filter to GetFeatureInfo FILTER allowed params. Trying to follow the path of the request, it seems that the filter is simply appended to layer subsetstring as it is. QgsFilters' aren't being used, right? LIKE was just added in https://github.com/qgis/QGIS/commit/ddc0f87f3e9113f4aeb693c46e446ed5eed7474d ILIKE was not working as we expected, therefore we didn't included it. - -- Ivan Minčík ivan.min...@gmail.com GPG: 0x79529A1E http://imincik.github.io/0x79529A1E.key ivan.min...@gista.skGPG: 0xD714B02C http://imincik.github.io/0xD714B02C.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC0uQAAoJEPfdLsR5UpoeDcwH/jKD8nAraEaUNd7VSgOfxoWk eHBLD7ChyHlFtDxUXy3/9YCftBcQtKwCL7FEQPywUvOz2sXqnybwehhpsRyPabaf V8AMLT5fr4nqKInANATiPRVaCHmQ0CoaL+MIzPJZgCu5enDJ6p+JBDOmq8kbfFCQ d5gkwhxUDwK7U9PlGjeELjUMl6ZOnlvllpzjrFGvc+UdpzGxGkKspAjhz/9tFaqn jv8pbN89Q7re5mf+NsGwJDXmnmBpessXAC7N70copO1mvic53dhcoOsZY8X6stqn F3j9990QnPMzRocog5OCiWOocBbyV+hZbdWqhVZXY+k7FNrodNihTPz6t3bjUkE= =BbG1 -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] [QGIS Mapserver] is QgsFilter ever used in GetFeatureInfo?
Hi Ivan, so ILIKE works bad in QGIS Desktop too? I will test it. Can you confirm QgsFilter is not being used (mmm... where is it ever used now?) giovanni Il 24/feb/2014 14:41 Ivan Mincik ivan.min...@gmail.com ha scritto: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/24/2014 01:45 PM, G. Allegri wrote: In an old feature request from me [1] I was suggesting to add LIKE/ILIKE filter to GetFeatureInfo FILTER allowed params. Trying to follow the path of the request, it seems that the filter is simply appended to layer subsetstring as it is. QgsFilters' aren't being used, right? LIKE was just added in https://github.com/qgis/QGIS/commit/ddc0f87f3e9113f4aeb693c46e446ed5eed7474d ILIKE was not working as we expected, therefore we didn't included it. - -- Ivan Minčík ivan.min...@gmail.com GPG: 0x79529A1E http://imincik.github.io/0x79529A1E.key ivan.min...@gista.skGPG: 0xD714B02C http://imincik.github.io/0xD714B02C.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC0uQAAoJEPfdLsR5UpoeDcwH/jKD8nAraEaUNd7VSgOfxoWk eHBLD7ChyHlFtDxUXy3/9YCftBcQtKwCL7FEQPywUvOz2sXqnybwehhpsRyPabaf V8AMLT5fr4nqKInANATiPRVaCHmQ0CoaL+MIzPJZgCu5enDJ6p+JBDOmq8kbfFCQ d5gkwhxUDwK7U9PlGjeELjUMl6ZOnlvllpzjrFGvc+UdpzGxGkKspAjhz/9tFaqn jv8pbN89Q7re5mf+NsGwJDXmnmBpessXAC7N70copO1mvic53dhcoOsZY8X6stqn F3j9990QnPMzRocog5OCiWOocBbyV+hZbdWqhVZXY+k7FNrodNihTPz6t3bjUkE= =BbG1 -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] Announcing the release of QGIS 2.2
Excellent work, thanks guys. Just a thought, but as part of the release process (I'm guessing there's a big list of things to do somewhere) I'd suggest updating the Affected Version on redmine to whatever the newest version is. There's no 2.2.0 on there currently. Cheers, Jonathan On 22 February 2014 08:58, Jürgen E. j...@norbit.de wrote: QGIS is a user friendly Open Source Geographic Information System that runs on Linux, Unix, Mac OSX, and Windows. We are very pleased to announce the release of QGIS 2.2 'Valmiera'. The emphasis on this release has been very much on polish and performance - we have added many new features, tweaks and enhancements to make the user interface more consistent and professional looking (and hopefully easier to use). The composer (used for creating print ready maps) has had a lot of work done to it to make it a more viable platform for creating great cartographic outputs. This is first release following our new four month release schedule that is meant to make new features and bugfixes available quicker and the development and new releases more predictable. In order to streamline the release process, we only release the source code today. The binaries will be created in close succession by the individual package maintainers. The source code is and the binaries soon will be available via the large download link on our home page: http://qgis.org If there is not yet a binary package for your platform on the above page, please check back regularly as packagers push out their work and the download page will reflect the new packages. A word of thanks to our contributors, donors and sponsors -- QGIS is a largely volunteer driven project, and is the work of a dedicated team of developers, documenters and supporters. We extend our thanks and gratitude for the many, many hours people have contributed to make this release happen. Many companies and organizations contribute back their improvements to QGIS and fund development of new features when they use it as their platform, and we are grateful for this and encourage others to do the same! We would also like to thank our sponsors and donors for helping to promote our work through their financial contributions. Our current sponsors are (QGIS Sponsorship is valid for one year): Gold Sponsor: Asia Air Survey (http://www.asiaairsurvey.com/) Silver Sponsor: State of Vorarlberg (http://www.vorarlberg.at) G.A.I.A. mbH (http://www.gaia-mbh.de/) Bronze Sponsors: ArguSoft GmbH Co KG (http://argusoft.de) Molitec (http://www.molitec.it/) A current list of donors who have made financial contributions large and small to the project can be seen here: http://qgis.org/en/site/about/sponsorship.html#list-of-donors If you would like to make a donation or sponsor our project, please visit *http://qgis.org/en/site/about/sponsorship.html#sponsorship* . QGIS is Free software and you are under no obligation to do so. Sponsoring QGIS helps us to fund our six monthly developer meetings, maintain project infrastructure and fund bug fixing efforts Visual tour of the new release: -- You can find a list of highlighted changes and new features listed on the detailed release announcement available here: * http://changelog.linfiniti.com/qgis/version/21/ * Give us your feedback: -- We welcome your feedback - please visit our issue tracker if you encounter an issue with the new release: http://hub.qgis.org/ Please consult the existing issues there before filing any new ones. Happy QGISing! Regards, The QGIS Team! -- Jürgen E. Fischer - QGIS Project Steering Committee Member == Please do not email me off-list with technical support questions. Using the lists will gain more exposure for your issues and the knowledge surrounding your issue will be shared with all. IRC: jef on #qgis at freenode.net == -- 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 -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic,
[Qgis-developer] Plugin [387] Processing unapproval notification.
Plugin Processing unapproval by alexbruy. The plugin version [387] Processing 2.-20131029 Experimental is now unapproved Link: http://plugins.qgis.org/plugins/processing/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Plugin [387] Processing approval notification.
Plugin Processing approval by alexbruy. The plugin version [387] Processing 2.-20131120 Experimental is now unapproved Link: http://plugins.qgis.org/plugins/processing/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] PyQT - How to get layer sending attributeValueChanged signal?
Hi, I would like to catch the layer or layer id that is sending attributeValueChanged signal. This signal carries only QgsFeatureId fid, int idx, const QVariant ) Any idea how to do this in a clean way? Cheers, Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/PyQT-How-to-get-layer-sending-attributeValueChanged-signal-tp5105532.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? I think it's a perception thing. Nightly build in my mind always means bleeding edge may or may not work, use at own risk. I'm aware that doesn't always mean *it will crash your computer, burn down your house, and spend your life savings on questionable drugs*, but it's certainly not what I see as a synonym for stable either. Every time I see a nightly, it always comes with a big scary caveat (QGIS does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This trains users not to use them. Taking one of the nightlies and re-branding it to something more amicable would get more folks to test it. Just copy and paste it and rename the file. :-) Cheers, Jonathan Very few average user will install a nightly development build, but you get an higher chance of getting a broader number of people (that interacts with QGIS in different ways) to test out your product before it's released. Why should it matter if we call it weekly snapshot, nightly build or prerelease? It's the same thing, just the tag is different. And installation is essential as easy as installing the stable release. It also helps channel what your describing as noise (i.e. users running into problems) into a better managed call for people to test and report. The noise will happen no matter what. But it might make some sense to trigger some of that noise (valid bugs and invalid RTFM cases) _before_ you release your final version via a pre-release social media and news site try this pre-release build :) It's really more a matter of presentation to the users than of actual work. Exactly. And that's what I meant with noise: tada, there's a new weekly snapshot/prerelease/nightly build - not users running into problems. Because I see that as the only significant difference to what we already have. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: 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 -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PyQT - How to get layer sending attributeValueChanged signal?
Hi Régis Calling sender() in your SLOT should return the QgsVectorLayer object There is also QSignalMapper [1] which has a cleaner concept, but it looks as if this will on the one hand help you to identify the source layer, but you will loose any other parameters, what's probably not your intent. Best Matthias [1] http://qt-project.org/doc/qt-4.8/qsignalmapper.html On Mon 24 Feb 2014 02:57:37 PM CET, Régis Haubourg wrote: Hi, I would like to catch the layer or layer id that is sending attributeValueChanged signal. This signal carries only QgsFeatureId fid, int idx, const QVariant ) Any idea how to do this in a clean way? Cheers, Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/PyQT-How-to-get-layer-sending-attributeValueChanged-signal-tp5105532.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ 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] Rendering feature symbol when feature is not visible
Hi all, I'm trying to render marker symbols that are bigger than the feature geometry bounding box. When the feature is not visible (because it is out of the current extent) the symbol isn't rendered. I think the code in the draw method of qgsvectorlayer.cpp is: QgsFeatureIterator fit = getFeatures( QgsFeatureRequest() .setFilterRect( rendererContext.extent() ) .setSubsetOfAttributes( attributes ) ); Ok, this is a expected behaviour, but is there anyway (using C++ API) to change this behaviour without extending QgsVectorLayer? I suppose that if I could pass the renderContext with the whole layer extent it would do the trick. Any suggestions or ideas? Thanks in advance. -- Jordi Torres ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
How about making a formal announcement (mailing list, website, wiki etc) telling the users that QGIS version 2.X is in feature freeze and therefore is sufficiently stable to be tested by end users? This may increase the number of testers. As an end user that uses QGIS for production, this is the only time I work with QGIS Master. On Mon, Feb 24, 2014 at 2:17 PM, Jonathan Moules jonathanmou...@warwickshire.gov.uk wrote: Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? I think it's a perception thing. Nightly build in my mind always means bleeding edge may or may not work, use at own risk. I'm aware that doesn't always mean *it will crash your computer, burn down your house, and spend your life savings on questionable drugs*, but it's certainly not what I see as a synonym for stable either. Every time I see a nightly, it always comes with a big scary caveat (QGIS does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This trains users not to use them. Taking one of the nightlies and re-branding it to something more amicable would get more folks to test it. Just copy and paste it and rename the file. :-) Cheers, Jonathan Very few average user will install a nightly development build, but you get an higher chance of getting a broader number of people (that interacts with QGIS in different ways) to test out your product before it's released. Why should it matter if we call it weekly snapshot, nightly build or prerelease? It's the same thing, just the tag is different. And installation is essential as easy as installing the stable release. It also helps channel what your describing as noise (i.e. users running into problems) into a better managed call for people to test and report. The noise will happen no matter what. But it might make some sense to trigger some of that noise (valid bugs and invalid RTFM cases) _before_ you release your final version via a pre-release social media and news site try this pre-release build :) It's really more a matter of presentation to the users than of actual work. Exactly. And that's what I meant with noise: tada, there's a new weekly snapshot/prerelease/nightly build - not users running into problems. Because I see that as the only significant difference to what we already have. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: 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 This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ 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 with Feature Form on QGIS 2.2
Hi, Yes - I can confirm that on Windows (OSGeo4W). Very annoying. I don't know when this bug was introduced - too bad I did not see it before the release. With this bug present I cannot roll out QGIS 2.2 in my organization - sad - it means I have to wait another 4 months to maybe have a useful release. We really need these 2.2x releases fixing the most urgent bugs. Andreas Am 24.02.2014 07:06, schrieb Denis Rouzaud: On 23. 02. 14 19:48, Pedro Venâncio wrote: Hi, Identify with Open feature form, if a single feature is identified opens both Feature Form and Identify Results window. Anyone confirms? I confirm. Very annoying! Would be worth a 2.2.1 ... ___ 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 with Feature Form on QGIS 2.2
Confirm on ubuntu 12.04 LTS from the UbuntuGIS PPA - Randal Hale, GISP North River Geographic Systems, Inc http://www.northrivergeographic.com 423.653.3611 rjh...@northrivergeographic.com mailto:rjh...@northrivergeographic.com twitter:rjhale http://about.me/rjhale On 02/24/2014 09:38 AM, Andreas Neumann wrote: Hi, Yes - I can confirm that on Windows (OSGeo4W). Very annoying. I don't know when this bug was introduced - too bad I did not see it before the release. With this bug present I cannot roll out QGIS 2.2 in my organization - sad - it means I have to wait another 4 months to maybe have a useful release. We really need these 2.2x releases fixing the most urgent bugs. Andreas Am 24.02.2014 07:06, schrieb Denis Rouzaud: On 23. 02. 14 19:48, Pedro Venâncio wrote: Hi, Identify with Open feature form, if a single feature is identified opens both Feature Form and Identify Results window. Anyone confirms? I confirm. Very annoying! Would be worth a 2.2.1 ... ___ 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 mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
Slightly deviating from the topic, but I'm quite fond of the GeoServer release process; they're revamping a little to offer better Long Term Support: http://geoserver.org/display/GEOS/GSIP+107+-+Extended+Release+Schedule I feel a similar system would solve most of QGIS' release problems: - Bugfix releases - LTS (if/when required) - Predictable releases (though now fixed by QGIS) - Clear test releases (betas and release candidates) In comparison the QGIS release system feels... haphazard I guess is the best word. I know the common complaint is a lack of a resources, but QGIS has far more resources than GeoServer - both in number of developers and the existence of a general fund. Just thought I'd put it out there. Cheers, Jonathan On 24 February 2014 14:41, Filipe Dias filipesd...@gmail.com wrote: How about making a formal announcement (mailing list, website, wiki etc) telling the users that QGIS version 2.X is in feature freeze and therefore is sufficiently stable to be tested by end users? This may increase the number of testers. As an end user that uses QGIS for production, this is the only time I work with QGIS Master. On Mon, Feb 24, 2014 at 2:17 PM, Jonathan Moules jonathanmou...@warwickshire.gov.uk wrote: Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? I think it's a perception thing. Nightly build in my mind always means bleeding edge may or may not work, use at own risk. I'm aware that doesn't always mean *it will crash your computer, burn down your house, and spend your life savings on questionable drugs*, but it's certainly not what I see as a synonym for stable either. Every time I see a nightly, it always comes with a big scary caveat (QGIS does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This trains users not to use them. Taking one of the nightlies and re-branding it to something more amicable would get more folks to test it. Just copy and paste it and rename the file. :-) Cheers, Jonathan Very few average user will install a nightly development build, but you get an higher chance of getting a broader number of people (that interacts with QGIS in different ways) to test out your product before it's released. Why should it matter if we call it weekly snapshot, nightly build or prerelease? It's the same thing, just the tag is different. And installation is essential as easy as installing the stable release. It also helps channel what your describing as noise (i.e. users running into problems) into a better managed call for people to test and report. The noise will happen no matter what. But it might make some sense to trigger some of that noise (valid bugs and invalid RTFM cases) _before_ you release your final version via a pre-release social media and news site try this pre-release build :) It's really more a matter of presentation to the users than of actual work. Exactly. And that's what I meant with noise: tada, there's a new weekly snapshot/prerelease/nightly build - not users running into problems. Because I see that as the only significant difference to what we already have. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: 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 This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer -- This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have
Re: [Qgis-developer] Post-release period of portable commits only?
Hi Jonathan, On Mon, 24. Feb 2014 at 14:17:44 +, Jonathan Moules wrote: Why not? We're talking about a feature freezed period!? The nightly build is a snapshot what what will get release. Where do you see a difference? I think it's a perception thing. Nightly build in my mind always means bleeding edge may or may not work, use at own risk. I'm aware that doesn't always mean *it will crash your computer, burn down your house, and spend your life savings on questionable drugs*, but it's certainly not what I see as a synonym for stable either. Sure, but that doesn't change that it's a misperception. It more like This is what we're going to release soon - it's not too bad and it's getting better every day, but if you don't try it and report problems, it's your responsibility if the release later eats your kids. ;) Every time I see a nightly, it always comes with a big scary caveat (QGIS does too - http://www.qgis.org/en/site/forusers/alldownloads.html ). This trains users not to use them. Taking one of the nightlies and re-branding it to something more amicable would get more folks to test it. Just copy and paste it and rename the file. :-) Or just remove all those wimpy warnings. It's in the smallprint (GPL) anyway. The users can not tests all they want, we still can't even be made responsible if the release does not eat kids. ;) Ok, seriously, I should probably emphasize in the freeze announcement, that it's mainly the users that are supposed to test the daily prereleases and weekly release candidates and report problems, while the developers work on reproducing and fixing already known or newly reported bugs. And the warnings on the download page should be changed to say, that testing nightly builds in the development phase are different thing than the daily prereleases in the freeze phase. Jürgen -- Jürgen E. Fischer norBIT GmbH Tel. +49-4931-918175-31 Dipl.-Inf. (FH) Rheinstraße 13Fax. +49-4931-918175-50 Software Engineer D-26506 Norden http://www.norbit.de QGIS PSC member (RM) Germany IRC: 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] PyQT - How to get layer sending attributeValueChanged signal?
Hi Matthias, thanks for the pointer. My plugin main class does not inherits from anything and I get the following error: line 173, in labelLayerModified sender = self.sender() AttributeError: EasyCustomLabeling instance has no attribute 'sender' Should I inherit my class from a higher QT or PyQt4 object, and which one? Cheers Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/PyQT-How-to-get-layer-sending-attributeValueChanged-signal-tp5105532p5105587.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Identify with Feature Form on QGIS 2.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Confirmed. Debian 7.3 with qgis 2.3 master updated this morning. Matteo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC2//AAoJEBy7UYf0gaEOZ8gIALX9YhsFuStCxtWJXYWz7/dd X5OgRfOE8ikQax6+BMISu6jS8PL/9Gspq3RYnAWEUjAn4lSw2PIUmkReMPaGvA87 52+fp4bl0+jMO5MRkIPOuPdEzebUrpRuaovm4lG/NsjA6xmyLVq/f6emqNIVnbxW mxRWRzThIHnXLP0P1BlFaSXnlsl5UE86Z1vueitnHUiElqv6ptuAoDoC0ZcvTRN4 NjXh79biWwnFDGb38NJovoTF7ithJpIA+7wtjF5+swnr1FeMKtju3oZ/TmAX5Wfy N0QdzaeeZSsMhV3fZyPKc70RdHi/R/Yj6qHogNzAByGafB7i9W49wVwxIIN0Af4= =eaNf -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Post-release period of portable commits only?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, seriously, I should probably emphasize in the freeze announcement, that it's mainly the users that are supposed to test the daily prereleases and weekly release candidates and report problems, while the developers work on reproducing and fixing already known or newly reported bugs. And the warnings on the download page should be changed to say, that testing nightly builds in the development phase are different thing than the daily prereleases in the freeze phase. Jürgen Jürgen, at first thank you for your work as a developer and RM. Time based releases are very good decision. I think that clear separation of nightly builds after a feature freeze from regular nightly builds (even if they are technically same) followed by loud public announcements will surely help to catch more bugs. Even if there is a no man power to maintain bugfix releases, please support people to commit backported fixes to release branches. I think many people realized importance of these bug releases and will offer a hand. I vote for Sandro's work flow - if there is at least one commit from latest minor release and at least 14 days of silence - release just a source code. Other things will follow upon volunteer base. - -- Ivan Minčík ivan.min...@gmail.com GPG: 0x79529A1E http://imincik.github.io/0x79529A1E.key ivan.min...@gista.skGPG: 0xD714B02C http://imincik.github.io/0xD714B02C.key -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC3IbAAoJEPfdLsR5Upoee0AIAI/zVrB5YiEV4dqR/BUx5/HF YX7ml6wNL+utmALAH+w06Ilzkem/4fLHk4IdWgjuTH/goSkypQeZF6vchrphc/zC frSpoSdQ3/ls+CemTQQv2aRkE3R3y91qMlx4mVrI0/i3WobjEsSvjWOEyjcaoG+b 9lBpY+6jHyrUpRP+fu0tE2fE0dE3+i660YpWYNeGHX66uFNEBfVhDhkDXdkuGxXV 25F+g32fD3C+koeA1ynqpht2tcrzOYnnAmmoerH5Z9cS1f+SwoomAjJGmnrnED1D VDfvS3mWKAaOpjy7N0FSrAyAQ7tLnOXuY3AQriokI3eBivjQ+uRfAUFgp+FQtDI= =BmOT -END PGP SIGNATURE- ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] PyQT - How to get layer sending attributeValueChanged signal?
A followup: I had my class inherit from QObject (first time doing that for me) and I catch the sender correctly. Strangely, I catch the signal twice, so maybe inherinting from QObject triggers another signalk somewhere.. Cheers -Message d'origine- De : Matthias Kuhn [mailto:matthias.k...@gmx.ch] Envoyé : lundi 24 février 2014 15:21 À : HAUBOURG Cc : qgis-developer@lists.osgeo.org Objet : Re: [Qgis-developer] PyQT - How to get layer sending attributeValueChanged signal? Hi Régis Calling sender() in your SLOT should return the QgsVectorLayer object There is also QSignalMapper [1] which has a cleaner concept, but it looks as if this will on the one hand help you to identify the source layer, but you will loose any other parameters, what's probably not your intent. Best Matthias [1] http://qt-project.org/doc/qt-4.8/qsignalmapper.html On Mon 24 Feb 2014 02:57:37 PM CET, Régis Haubourg wrote: Hi, I would like to catch the layer or layer id that is sending attributeValueChanged signal. This signal carries only QgsFeatureId fid, int idx, const QVariant ) Any idea how to do this in a clean way? Cheers, Régis -- View this message in context: http://osgeo-org.1560.x6.nabble.com/PyQT-How-to-get-layer-sending- attr ibuteValueChanged-signal-tp5105532.html Sent from the Quantum GIS - Developer mailing list archive at Nabble.com. ___ 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 MetaSearch Catalogue Client 0.1.0 released
Hi Stefan: great idea! FYI there is discussion on this at https://github.com/geopython/MetaSearch/pull/31#issuecomment-35818883, the output of which we'll place on the MetaSearch w.r.t. how to get your CSW added to default connections. If someone can put out a call to qgis-user, that would be great. On Mon, Feb 24, 2014 at 3:54 AM, Blumentrath, Stefan stefan.blumentr...@nina.no wrote: Hi Tom, I see you started collecting Meta Data Catalogues (at least on national scale) for the default services in the plugin. I like the idea very much. What about asking (QGIS) users explicitly to provide addresses for their countries? Such a collection would be really valuable (especially for people working across borders) and maybe also of interest for other projects as there are already comparable initiatives on collecting information on available data: http://wiki.osgeo.org/wiki/Geodata_Discovery_Working_Group http://grasswiki.osgeo.org/wiki/Global_datasets What do you think? Cheers, Stefan -Original Message- From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom Kralidis Sent: 19. februar 2014 13:00 To: Blumentrath, Stefan Cc: qgis-developer@lists.osgeo.org Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released Hi Stefan: thanks for the info. This is the dreaded metadata link types issue. If possible, can you open an issue on this so we can discuss this in the ticket? Thanks ..Tom On Wed, 19 Feb 2014, Blumentrath, Stefan wrote: Date: Wed, 19 Feb 2014 11:54:04 + From: Blumentrath, Stefan stefan.blumentr...@nina.no To: Tom Kralidis tomkrali...@gmail.com Cc: qgis-developer@lists.osgeo.org qgis-developer@lists.osgeo.org Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released Done. BTW, the problem that I could not add WMS / WFS is likely to be on the CSW side and not the client side, cause it worked for some WMS... I was using the CSW for official map data in Norway provided by geonorge: http://www.geonorge.no/geonetwork/srv/no/csw? There are several / many WMS listed which cannot be added... Would you mind double checking if this is a server-side problem? Cheers Stefan -Original Message- From: Tom Kralidis [mailto:tom.krali...@gmail.com] On Behalf Of Tom Kralidis Sent: 19. februar 2014 12:32 To: Blumentrath, Stefan Cc: qgis-developer@lists.osgeo.org Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released Hi Stefan: thanks for the info/kind words. Yes, can you file a ticket at https://github.com/geopython/MetaSearch/issues/new with the steps taken, so we can reproduce and fix the issue. Thanks ..Tom On Wed, 19 Feb 2014, Blumentrath, Stefan wrote: Date: Wed, 19 Feb 2014 08:06:59 + From: Blumentrath, Stefan stefan.blumentr...@nina.no To: Tom Kralidis tomkrali...@gmail.com, qgis-developer@lists.osgeo.org qgis-developer@lists.osgeo.org Subject: RE: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released Hi Tom, Thank you (and your team) very much for this excellent plugin! Very valuable! I tested version 0.1.1 (in QGIS 2.0.1 on Win7) and love it already. Adding WMS/WCS/WFS however does not seem to be active yet, and using the back arrows throws an error: Traceback (most recent call last): File C:\Users\ninsbl/.qgis2/python/plugins\MetaSearch\dialogs\maindialog.py, line 572, in navigate if res == QMessageBox.Ok: UnboundLocalError: local variable 'res' referenced before assignment Should I file a ticket? Still the plugin is already very useful and personally I think it should make it to QGIS core in the long run! So, thanks again, Stefan -Original Message- From: qgis-developer-boun...@lists.osgeo.org [mailto:qgis-developer-boun...@lists.osgeo.org] On Behalf Of Tom Kralidis Sent: 18. februar 2014 21:16 To: qgis-developer@lists.osgeo.org Subject: [Qgis-developer] QGIS MetaSearch Catalogue Client 0.1.0 released The MetaSearch team announces the release of MetaSearch 0.1.0. The 0.1.0 release marks the initial offering of a CSW client for QGIS 2, with significant features to enable plug and play interoperability with OGC CSW services. - find and bind functionality allowing users to discover and add layers from WMS, WFS, WCS, or WMTS services dynamically to the map - template-based service and record metadata view, allowing for custom templating of responses - visual footprint of CSW results - display of all metadata access links, allowing users to click/download data to add to QGIS - spatial and aspatial querying of CSW services Version 0.1.0 represents a significant engineering effort to bring CSW support for QGIS 2, make the codebase sustainable/extensible and easy for developers and documentation teams to make contributions. Longer term plans include: - supporting other catalog APIs (CKAN, etc.) - making MetaSearch part of QGIS core -
Re: [Qgis-developer] Post-release period of portable commits only?
Hi, On Mon, Feb 24, 2014 at 7:41 AM, Filipe Dias filipesd...@gmail.com wrote: How about making a formal announcement (mailing list, website, wiki etc) telling the users that QGIS version 2.X is in feature freeze and therefore is sufficiently stable to be tested by end users? This may increase the number of testers. As an end user that uses QGIS for production, this is the only time I work with QGIS Master. On Mon, Feb 24, 2014 at 8:54 AM, Jürgen E. j...@norbit.de wrote: -- 8--snip Ok, seriously, I should probably emphasize in the freeze announcement, that it's mainly the users that are supposed to test the daily prereleases and weekly release candidates and report problems, while the developers work on reproducing and fixing already known or newly reported bugs. And the warnings on the download page should be changed to say, that testing nightly builds in the development phase are different thing than the daily prereleases in the freeze phase. I think those two posts really do sum it up. The project just needs to communicate better with the user community that the weeks between the feature freeze and release are their chance to make a difference, by testing the 'release candidate' (or whatever it going to be called), or be prepared to wait 4 months. +1 I'm all for these changes. I don't think the idea I proposed in the original post is any better, excepting the inclusion of a larger user base, which still doesn't mean better testing, though. If the majority of users 'know' that they have several weeks every 4 months to directly affect change/bugs right before a release, that should be good enough. Also, would be good to list that right on the Roadmap schedule [0], e.g.: WEEK DATE EVENT 21 23.02.3 freeze begins, release candidate [0] http://qgis.org/en/site/getinvolved/development/index.html#road-map Regards, Larry ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Plugin [32] Value Tool approval notification.
Plugin Value Tool approval by etourigny. The plugin version [32] Value Tool 0.8.2 is now approved Link: http://plugins.qgis.org/plugins/valuetool/ ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
[Qgis-developer] Still can't select features prior to dissolve
// This works from osgeo import ogr canvas = qgis.utils.iface.mapCanvas() allLayers = canvas.layers() for i in allLayers: i.selectAll(); print i.name(); print i.selectedFeatureCount() (In the python Console) Above you use the current layer (i) to i.selectAll(); How do you do a selection using attribute values such as i.selectFeatures(LWFLAG != 'P') to set the selected features for the dissolve function? qgis.analysis.QgsGeometryAnalyzer.dissolve?4(QgsVectorLayer, QString, bool onlySelectedFeatures=True, int uniqueIdField=-1) - bool Michael McInnis 6033 44th Ave. N.E. Seattle, WA 98115 206 517-4701 ___ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
Re: [Qgis-developer] Multi-threading rendering merged to master
Hi Martin, This is just awesome work! Unfortunately, all but the simplest labeling tests (default labels of mm unit) fail, especially any that utilize labels in map units. In your forthcoming detailed description of changes you mentioned, could you add some info on what may have changed with regards to output resolution? Sorry, I haven't read all previous list threads concerning your work yet. I'm going to go back to a 2.2 build and work on a semi-complete suite of labeling tests. Then, port the unit tests and control images to master, so we can see the differences between then and post-multi-threading commits. For now, labeling output is ~90% broken, resolution-wise, across all outputs. Regards, Larry On Mon, Feb 24, 2014 at 2:27 AM, Martin Dobias wonder...@gmail.com wrote: Hi Mathieu On Mon, Feb 24, 2014 at 9:52 AM, Mathieu Pellerin nirvn.a...@gmail.com wrote: Martin, Fantastic work; I knew to expect a better rendering experience, yet I was caught by surprise at how much of a positive difference it makes. Few things from my 10-minutes play with it: * The map overview extend is broken, its extend goes way, way beyond the extend of the sum of all the layers in a given project In my quick test everything seems to work fine, I will need more details about the issue - feel free to file a bug report. * The 'xxx' option doesn't seem to be taken into consideration, the parallel rendering is always activated on my machine irrespective of whether I checked the box or not. Works fine for me... but there are two different concepts: 1. rendering in background - GUI is responsive even while the map is being rendered - this is always on 2. parallel vs sequential rendering - in sequential mode, there is just one job that renders everything - in parallel mode, the job is split into several jobs (one job per map layer) and jobs can therefore use multiple cores Are you sure you are not referring to point 1? Also, it is worth noting that parallel rendering may bring improvements only when there is more than one layer to render. * Half of the times I exited QGIS, the application process was not terminating and this error message was thrown: *** Error in `/home/webmaster/apps/bin/qgis': corrupted double-linked list: 0x0a0680f0 ***; I had to manually kill the process I had this problem too - due to some garbage in the build directory (incompatible plugin DLLs). Try to run QGIS with --noplugins option. But better do a clean build. 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] Identify with Feature Form on QGIS 2.2
hmmm that is a real bugger. Yeah I think kind of thing warrants a bug fix release. This will kill QGIS for most users who do data entry, which is most of the people I know. - Nathan On Tue, Feb 25, 2014 at 2:15 AM, matteo matteo.ghe...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Confirmed. Debian 7.3 with qgis 2.3 master updated this morning. Matteo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC2//AAoJEBy7UYf0gaEOZ8gIALX9YhsFuStCxtWJXYWz7/dd X5OgRfOE8ikQax6+BMISu6jS8PL/9Gspq3RYnAWEUjAn4lSw2PIUmkReMPaGvA87 52+fp4bl0+jMO5MRkIPOuPdEzebUrpRuaovm4lG/NsjA6xmyLVq/f6emqNIVnbxW mxRWRzThIHnXLP0P1BlFaSXnlsl5UE86Z1vueitnHUiElqv6ptuAoDoC0ZcvTRN4 NjXh79biWwnFDGb38NJovoTF7ithJpIA+7wtjF5+swnr1FeMKtju3oZ/TmAX5Wfy N0QdzaeeZSsMhV3fZyPKc70RdHi/R/Yj6qHogNzAByGafB7i9W49wVwxIIN0Af4= =eaNf -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] Identify with Feature Form on QGIS 2.2
The workaround for this is to have the identify dialog docked which will stop it opening over the top. I have hidden mine behind the browser dock so it doesn't show up all the time. - Nathan On Tue, Feb 25, 2014 at 12:09 PM, Nathan Woodrow madman...@gmail.comwrote: hmmm that is a real bugger. Yeah I think kind of thing warrants a bug fix release. This will kill QGIS for most users who do data entry, which is most of the people I know. - Nathan On Tue, Feb 25, 2014 at 2:15 AM, matteo matteo.ghe...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Confirmed. Debian 7.3 with qgis 2.3 master updated this morning. Matteo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQEcBAEBAgAGBQJTC2//AAoJEBy7UYf0gaEOZ8gIALX9YhsFuStCxtWJXYWz7/dd X5OgRfOE8ikQax6+BMISu6jS8PL/9Gspq3RYnAWEUjAn4lSw2PIUmkReMPaGvA87 52+fp4bl0+jMO5MRkIPOuPdEzebUrpRuaovm4lG/NsjA6xmyLVq/f6emqNIVnbxW mxRWRzThIHnXLP0P1BlFaSXnlsl5UE86Z1vueitnHUiElqv6ptuAoDoC0ZcvTRN4 NjXh79biWwnFDGb38NJovoTF7ithJpIA+7wtjF5+swnr1FeMKtju3oZ/TmAX5Wfy N0QdzaeeZSsMhV3fZyPKc70RdHi/R/Yj6qHogNzAByGafB7i9W49wVwxIIN0Af4= =eaNf -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
[Qgis-developer] Some notes of 2.2. OpenSuse 12.3 release
Hi, thanks for all developers of huge and fantastic work again. I've OpenSuse 12.3 updated about per midnight (GMT 24.2.2014 23:00). and qgis2-2.2.0-6.1 I'd some notices of small "bugs". I was not able to use other machinery so I don't know .. 1. Manage and Install Plugins ... - Upgradeable ; I've two left after I upgraded all others. mmqgis and Qgis2threejs both tell "There is a new version available" I've tried both Upgrade all and Upgrade plugin. Restarted QGIS and tried again. They just won't want to be upgraded. Then I uninstalled mmqgis and installed again. Now it has been upgraded but is again in the list of upgradeable. If You look the numbering where I expect the error lie ? Installed version: 2014.01.06 (in /home/kari/.qgis2/python/plugins/mmqgis) Available version: 2014.1.6 (in QGIS Official Plugin Repository) - and uninstall-installresult was also Installed version: 0.06 (in /home/kari/.qgis2/python/plugins/Qgis2threejs) Available version: 0.6 (in QGIS Official Plugin Repository) - those leading zeroes ? 2. jp2 (Jpeg2000) files don't work/render at all. That was not a surprise in OpenSuse. Have to force kill and restart qgis. 3. in About - License is missing (totally white) ;) Regards, Kari PS. Installation QGIS version 2.2.0-Valmiera QGIS code revision exported Compiled against Qt 4.8.4 Running against Qt 4.8.4 Compiled against GDAL/OGR 1.10.1 Running against GDAL/OGR 1.10.1 Compiled against GEOS 3.4.2-CAPI-1.8.2 Running against GEOS 3.4.2-CAPI-1.8.2 r3921 PostgreSQL Client Version 9.2.4 SpatiaLite Version 4.1.1 QWT Version 5.2.3 PROJ.4 Version 480 QScintilla2 Version -- 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
