Hi Luigi (Gino),
On Fri, Jun 14, 2013 at 12:00 AM, Gino Pirelli lui...@gmail.com wrote:
returnCheck = true
try:
returnValue = variable
except ValueError:
returnCheck = false
the previous code doesn't raise any ValueError without an explicit cast.
If conversion goes wrong you
Hi I'm Luigi Pirelli
I'm porting rt_mapserver_export to the new 2.0 SIP api
I found another case where it's necessary to pay attention (and could be
added in the wiki:
http://hub.qgis.org/wiki/quantum-gis/Python_plugin_API_changes_from_18_to_20
as the case before about floats, a simple replace
On Sun, Jun 09, 2013 at 10:27:51AM +0200, Borys Jurgiel wrote:
Actually no breaking change happened now, there would be just MUCH more
switches (assuming that e.g. each formerly QString-type variable may be
either
QString or unicode). So in the simplest plugins you can still use them and
Hey everyone,
You are
On Sat, Jun 8, 2013 at 9:35 PM, Nathan Woodrow madman...@gmail.com wrote:
Hey all,
The new SIP API has been merged now. There are still a few things to
clean up in some of the core plugins but it is merged for wider testing.
I don't expect to find any major issues.
Hey everyone,
You are now free to upload your new 2.0 API version of your plugins to the
QGIS plugin repo. Remember to set qgisMinimumVersion and qgisMaximumVersion
in your metadata.txt so that plugin repo and installer get the right
version of the plugin.
An updated conversion guide is at
Nathan,
bear with me I have a really basic question concerning you mail and
advice [1]. I use quite a lot of QtSql.QSqlQuerys in my plugins to
retrieve data from a PostgreSQL database. The value() method currently
returns a QVariant. What is it supposed to return in the future or are
only
Hey Bernhard,
All PyQt functions are affected. QSqlQuery.Value will now return a native
Python type.
- Nathan
On Mon, Jun 10, 2013 at 11:03 PM, Bernhard Ströbl
bernhard.stro...@jena.dewrote:
Nathan,
bear with me I have a really basic question concerning you mail and advice
[1]. I use
I am getting error on startup:
An error occured during execution of following code:
pyplugin_installer.instance().showPluginManagerWhenReady()
...
url = settings.value(key+/url, , type=unicode)
TypeError: QSettings.value(QString, QVariant defaultValue=QVariant()):
'type' is not a valid keyword
Dnia poniedziałek, 10 czerwca 2013 o 14:54:45 Nathan Woodrow napisał(a):
Hey everyone,
You are now free to upload your new 2.0 API version of your plugins to the
QGIS plugin repo. Remember to set qgisMinimumVersion and qgisMaximumVersion
in your metadata.txt so that plugin repo and installer
I have been working on a fix for this today, which is open as a pull
request at the moment [1]
We have been discussing this on IRC today, Main points:
On the C++ side, there are invalid and NULL QVariants. On the python
side there is only None, therefore QPyNullVariant has been
introduced. As we
On 08-06-13 13:35, Nathan Woodrow wrote:
Hey all,
The new SIP API has been merged now. There are still a few things to
clean up in some of the core plugins but it is merged for wider testing.
I don't expect to find any major issues.
Cool, THANKS!
I would recommend creating a branch in
I would recommend creating a branch in git with your new 2.0 version and
be ready to upload it when I give the go ahead.
Is it not 'better' to branch your old version in the 1.8.x branch, and
do further work in master (for future releases)?
I believe Nathan meens to not upload the new
On Sun, Jun 9, 2013 at 6:27 PM, Borys Jurgiel li...@borysjurgiel.pl wrote:
Actually no breaking change happened now, there would be just MUCH more
switches (assuming that e.g. each formerly QString-type variable may be
either
QString or unicode). So in the simplest plugins you can still use
On 09-06-13 10:47, Nathan Woodrow wrote:
Technically this can be done for smaller plugins like Borys said.
Something like:
I think only for VERY small plugins. In the (not so very big plugins) I
do it was already getting messy.
And by the why, a big thank you for all the great work and
I am checking the SEXTANTE adaptation to the new SIP API, and
everything is fine. The only strange thing that I found is how null
values are handled when they appear in a vector layer field. It seems
that, in that case, a QVariant is still returned (particularly a
QPyNullVariant object). Wouldn't
Victor,
Which code is returning a QVariant null?
- Nathan
On Mon, Jun 10, 2013 at 12:01 AM, Victor Olaya vola...@gmail.com wrote:
I am checking the SEXTANTE adaptation to the new SIP API, and
everything is fine. The only strange thing that I found is how null
values are handled when they
On Son 09 Jun 2013 16:02:57 CEST, Nathan Woodrow wrote:
Victor,
Which code is returning a QVariant null?
feat['myAttribute']
returns QPyNullVariant for all features which have a NULL value in the
field myAttribute.
None would work for me as well. But I'm not sure, why PyQt introduced
this
Ok I'll check it out and see if it can be converted.
-- Nathan
On Mon, Jun 10, 2013 at 12:19 AM, Matthias Kuhn matthias.k...@gmx.chwrote:
On Son 09 Jun 2013 16:02:57 CEST, Nathan Woodrow wrote:
Victor,
Which code is returning a QVariant null?
feat['myAttribute']
returns
I find that same behaviour that Matthias confirms.
I guess it should be fixed, since it forces developers to add extra
code to handle that case, and it can be very confusing (all other
Qvariants are removed, except in this case...)
Hopefully it will be easy to fix.
Thanks in advance!
Victor
Just found another case which requires special attention:
Given a feature with myInt=5
Old API:
feat['myInt'].toFloat() / 10
0.5
New API:
feat['myInt'] / 10
0
Better:
float( feat['myInt'] ) / 10
0.5
Or:
feat['myInt'] / 10.0
0.5
I guess that's not something we can fix in a generic
I think it is a good idea to force the data type using str(),
unicode(), int(), float(), etc... Maybe a bit redundant, but probably
a safer strategy now
2013/6/9 Matthias Kuhn matthias.k...@gmx.ch:
Just found another case which requires special attention:
Given a feature with myInt=5
Old
And the NULL values?
try:
a = float(b['c'])
except TypeError:
a = None
Do you have a more elegant idea?
On Son 09 Jun 2013 16:46:42 CEST, Victor Olaya wrote:
I think it is a good idea to force the data type using str(),
unicode(), int(), float(), etc... Maybe a bit redundant, but
From: Matthias Kuhn
Sent: 10/06/2013 12:42 AM
To: Victor Olaya
Cc: Richard Duivenvoorde; qgis-developer@lists.osgeo.org; Nathan Woodrow
Subject: Re: [Qgis-developer] SIP API Update merged. Attention plugin
authors
Just found another case which requires special attention:
Given a feature with myInt=5
Hey all,
The new SIP API has been merged now. There are still a few things to clean
up in some of the core plugins but it is merged for wider testing. I
don't expect to find any major issues.
I have written a conversion guide here:
https://gist.github.com/NathanW2/5734767
Plugin authors
24 matches
Mail list logo
