[QGIS-Developer] Plugin [1956] Open Hazards PH approval notification.

[noreply]

Plugin Open Hazards PH approval by pcav.
The plugin version "[1956] Open Hazards PH 0.1.1 Experimental" is now approved
Link: http://plugins.qgis.org/plugins/open_hazards_ph/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] FYI: Qt LTS Releases To Be Restricted To Commercial Customers

[Paolo Cavallini]

Hi all

Il 28/01/20 00:27, Nyall Dawson ha scritto:

> Here's my analysis of the impact it will have on QGIS 

thanks for the analysis Nyall, quite reassuring.
Juergen, any further comment?
Cheers.
-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Why does QGIS frequently get flagged by Trend Micro?

[Greg Troxel]

"Moskovitz, Bob@DOC"  writes:

> Hello All,
>
> I've noticed that QGIS 3.10.2-2 (and previous versions) would crash and then 
> get flagged by Trend Micro with the following 2 "Security Threat":
>
>   *   TSC_GENCLEAN 
> https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/TSC_GENCLEAN
>   *   Unauthorized File Encryption 
> https://www.trendmicro.com/vinfo/us/threat-encyclopedia/search/unauthorized%20file%20encryption
>
> I don't know if the crashes are caused by the Trend Micro, but it would be 
> great if I can figure out what QGIS is doing to trigger Trend.  Can anyone 
> tell me how these "Security Threats" are related to how QGIS works?

This question should be addressed to Trend Micro, to explain what it is
they are flagging, and why it is a legitimate complaint.  Software like
Trend Micro is almost always proprietary and opaque, so people other
than the company simply cannot answer questions like the one you are
asking.  I would not be surprised if it is some pattern-matching false
positive.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] FYI: Qt LTS Releases To Be Restricted To Commercial Customers

[Even Rouault]

On lundi 27 janvier 2020 17:35:22 CET Paolo Cavallini wrote:
> Thanks Even. As I read it, this essentially means we are more or less
> forced to use the latest version, not the LTS (or to stick to an older
> one). This could mean more bugs.

QGIS sources aren't bound to a particular QT version. Currently the requirement 
is just >= 5.9
So pretty much depends on what binary distributions actually ship.

I've tried to follow the discussion on the thread announcing it at
https://lists.qt-project.org/pipermail/development/2020-January/thread.html#38316
but it is still unclear if QT Company will publish the source of their LTS 
branches or not.
At the very least, bugfixes that apply to the latest -dev branch, and older 
branches,
will be available, so people can *potentially* backport them (pending extra 
burden for
FOSS QT, typically Linux ones, distribution maintainers to scrutanize what must 
be
backported, which according to [1] would be very hard to do). If they don't 
publish the
source of the LTS branches, and a bug only affects a LTS branch and not the 
latest -dev branch, then
non-commercial customers will not benefit from it.

A lot of speculations in the above thoughts, and from a outsider of the working 
of the QT
project. If QT Company has the ultimate say to which branches are maintained or 
not,
or if other companies might jump in to bring back public LTS support...

Anyway, somewhat related to the above considerations, it looks like as far as 
OSGeo4W is
concerned, there's a QT 5.11.3 release with security fixes (cf [2]) whereas 
5.11.2 is shipped now.
But as the 5.11 branch is no maintained anymore, it is
well possible that 5.11.3 contains know issues, including security related ones,
fixed in later versions.
The 5.12 series is (should we say "was" now ?) announced as the LTS one with 
support until
5.12.2021 according to [3], so could be (have been?) a good candidate to track.
Perhaps some upgrade policy should be defined (only makes sense if there's 
manpower to
implement it of course)

Even

[1] https://lists.qt-project.org/pipermail/development/2020-January/038388.html
[2] 
https://www.qt.io/blog/2018/12/04/qt-5-11-3-released-important-security-updates
[3] https://en.wikipedia.org/wiki/Qt_version_history

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Data provider default values and default value clause

[Nyall Dawson]

On Mon, 27 Jan 2020 at 18:02, Alessandro Pasotti  wrote:
>
> Hi Nyall,
>
> thank you for confirming my worst nightmares :)
>
> Unfortunately, since the data providers are certainly a foundation component 
> of QGIS, these behavior inconsistencies lead to issues in client code (GUI/UX 
> mainly but probably also in QgsVectorLayerUtils create features functions) 
> and I believe we should try hard to find a solution.

Well - I realise it's nitpicking, but I don't see this as a bug,
rather as a feature request. Before the default value/ default value
clause api was introduced we had NO way of differentiating these two,
for any providers. We'd treat everything as a clause and there was
lots of bugs as a result. When it was introduced the majority of
providers were updated to utilise it, with the expectation of those
which **couldn't** (due to backend limitations). For those providers
there was no regressions -- they just didn't get the improved
handling/user experience that the other providers gained. It's
technically a "feature request" to somehow upgrade the remainder and
find ways to differentiate default clauses from literal values for
those providers.

There may well be implementation bugs here (there always is!), but I
think the existing API is fine and gives a sufficient level of
distinction between the two.

> Do you think it is a wast of time (because as you mentioned some providers 
> can't tell the difference between a literal and an expression)?

...Possibly? When I added them I did look into these backends with no
luck, but you may have better luck then I did! (or just run into the
same dead-ends...)

Nyall

>
> I've done a PR that does not completely fix all the issues but at least adds 
> some tests and fixes a few things: https://github.com/qgis/QGIS/pull/34012
>
>
>
> On Mon, Jan 27, 2020 at 7:44 AM Nyall Dawson  wrote:
>>
>> On Fri, 24 Jan 2020 at 19:28, Alessandro Pasotti  wrote:
>> >
>>
>> > 1. From the docs it seems that the defaultValueClause() should ONLY return 
>> > clauses (like sequences, functions, CURRENT_TIMESTAMP etc.) and should NOT 
>> > return literal defaults.
>>
>> Correct. However -- not all providers are completely well behaved in
>> this regard. Some of these are because of limitations on the provider
>> itself, e.g. there is no way to different literal defaults from
>> clause-type defaults on the associated backend. When we can't
>> differentiate the two, we err on the side of returning a
>> possible-literal value from defaultValueClause (and not the reverse
>> and accidentally return a non-literal value from defaultValue() ).
>>
>> > 2. From the docs it seems that defaultValue() should return ONLY literal 
>> > defaults and NOT functions, ::nextval and friends
>>
>> Correct (and should ALWAYS be the case)
>>
>> > 3. OGR provider does return the actual client-side calculated value when 
>> > calling defaultValue() ONLY in case of literal defaults and 
>> > CURRENT_TIMESTAMP, CURRENT_DATE and CURRENT_TIME, it returns the clause 
>> > definition in all other cases, is this correct?
>>
>> Yes - it's deliberate, even thought it slightly violates the above
>> answer to (2) in that for this provider we pre-calculate these
>> quasi-literal values on the qgis side.
>>
>> > 4. postgres provider in case the property EvaluateDefaultValues is true 
>> > does something more and send the clause to the server for evaluation, 
>> > returning the calculated value, otherwise it returns the clause definition.
>>
>> That's correct also, and by design. As per the warnings in the
>> defaultValue() docs, defaultValue calls are potentially dangerous to
>> make and should only ever be done when creating features (and in that
>> situation, only ever called once per field per feature). Otherwise
>> when EvaluateDefaultValues is true we run the risk of evaluating
>> sequences multiple times for a single feature, causing "gaps" in the
>> sequence.
>>
>> > 5. What to return in case of no defaults? Depending on provider and field 
>> > types, some implementations return a NULL (QVariant()), some others return 
>> > a Python None.
>>
>> Slight correction: QVariant() != Python NULL. Rather QVariant() ==
>> Python None, and QVariant( QVariant::Int ) == Python NULL. The c++ api
>> doesn't usually differentiate between the two and QVariant() is more
>> commonly used. (And I personally think in 4.0 we should completely
>> remove the PyQGIS NULL/QVariant( QVariant::Int ) distinctions -- they
>> add much complexity to code without compelling enough benefits).
>>
>> Short answer: return QVariant() when no default literal exists.
>>
>> > So, I'm confused about the expected behavior, if the documentation of 
>> > defaultValue() and defaultValueClause() is correct then the provider 
>> > implementations are (at least for some of them) wrong.
>>
>> Hope that clarifies!
>>
>> Nyall
>>
>> >
>> > I'd like to hear other developer's opinion before proceeding with a fix 
>> > for the a.m. providers.
>> >
>> > Thank you 

Re: [QGIS-Developer] FYI: Qt LTS Releases To Be Restricted To Commercial Customers

[Nyall Dawson]

On Tue, 28 Jan 2020 at 02:34, Paolo Cavallini  wrote:
>
> Thanks Even. As I read it, this essentially means we are more or less
> forced to use the latest version, not the LTS (or to stick to an older
> one). This could mean more bugs.
> Any deeper insight?
> Cheers.

It's an unexpected move, but I can honestly understand the rationale behind it.

Here's my analysis of the impact it will have on QGIS (using quotes
from 
https://lists.qt-project.org/pipermail/development/2020-January/038316.html)

> "One is a change in policy regarding the LTS releases, where the LTS part of 
> a release is in the future going to be restricted to commercial customers. 
> All bug fixes will (as agreed on the Qt Contributor Summit) go into dev 
> first. Backporting bug fixes is something that the Qt Company will take care 
> of for these LTS branches. We’ve seen over the past that LTS support is 
> something mainly required by large companies, and should hopefully help us 
> get some more commercial support for developing Qt further."

Doesn't greatly affect us, since this change mainly has distro level
impact. Of our supported platforms, we have:

- linux: Qt releases are a distro responsibility, so no direct impact
to us there. Distros will either need to manually backport fixes from
Qt current releases to older releases, or update more frequently to
newer Qt releases. I can understand this will be painful for distro
level Qt maintainers, but for our users there's likely to be minimal
impact, and possibly we'll see a **better** end user experience IF
distros decide to start updating Qt major releases more frequently.
- mac: Zero impact. The mac builds use infrastructure that regularly
updates to the current Qt versions and don't use LTR releases.
- Windows: Zero impact -- osgeo4w doesn't use Qt LTR releases, and
doesn't regularly update Qt versions. It's done on an ad-hoc basis and
will likely continue this way

On the flip side, if this move increases the revenue stream and
viability of the Qt company, then it's a GOOD thing for us.

> "The second change is that a Qt Account will be in the future required for 
> binary packages. Source code will continue to be available as currently. This 
> will simplify distribution and integration with the Marketplace. In addition, 
> we want open source users to contribute to Qt or the Qt ecosystem. Doing so 
> is only possible with a valid Qt Account (Jira, code review and the forums 
> all require a Qt Account)."

Almost zero impact. A bit of annoyance for the handful of QGIS
developers who build QGIS using custom (non distro) Qt versions or who
use upstream Qt Creator releases, but likely all those already have Qt
Accounts for use on the Qt bug tracker.

> "The third change is that The Qt Company will in the future also offer a 
> lower priced product for small businesses. That small business product is btw 
> not limited to mobile like the one Digia had some years ago, but covers all 
> of Qt for Device Creation."

Zero impact.

Lastly, from https://www.qt.io/blog/qt-offering-changes-2020 :

> "The offline installer will become available to commercial licensees only"

This is the biggest impact. I understand that osgeo4w qt libraries are
based off the offline installer packages (correct me if I'm wrong here
Jürgen!). The consequence of this is that we'd need to self-build Qt
libraries for inclusion in osgeo4w and the QGIS installers. Outcome:
more work for the Windows installer maintainers̶.

Nyall
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] FYI: Qt LTS Releases To Be Restricted To Commercial Customers

[Régis Haubourg]

Wow, strange move for Qt !
We still lack a lot of detail though...
Régis



Le lun. 27 janv. 2020 à 17:25, Even Rouault  a
écrit :

> Hi,
>
> Just read this:
>
> https://www.phoronix.com/scan.php?page=news_item&px=Qt-Going-More-Commercial
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Why does QGIS frequently get flagged by Trend Micro?

[Moskovitz, Bob@DOC]

Hello All,

I've noticed that QGIS 3.10.2-2 (and previous versions) would crash and then 
get flagged by Trend Micro with the following 2 "Security Threat":

  *   TSC_GENCLEAN 
https://www.trendmicro.com/vinfo/us/threat-encyclopedia/malware/TSC_GENCLEAN
  *   Unauthorized File Encryption 
https://www.trendmicro.com/vinfo/us/threat-encyclopedia/search/unauthorized%20file%20encryption

I don't know if the crashes are caused by the Trend Micro, but it would be 
great if I can figure out what QGIS is doing to trigger Trend.  Can anyone tell 
me how these "Security Threats" are related to how QGIS works?

Thanks,
Bob

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] FYI: Qt LTS Releases To Be Restricted To Commercial Customers

[Paolo Cavallini]

Thanks Even. As I read it, this essentially means we are more or less
forced to use the latest version, not the LTS (or to stick to an older
one). This could mean more bugs.
Any deeper insight?
Cheers.

Il 27/01/20 17:25, Even Rouault ha scritto:
> Hi,
> 
> Just read this:
> https://www.phoronix.com/scan.php?page=news_item&px=Qt-Going-More-Commercial
> 
> Even
> 

-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] FYI: Qt LTS Releases To Be Restricted To Commercial Customers

[Even Rouault]

Hi,

Just read this:
https://www.phoronix.com/scan.php?page=news_item&px=Qt-Going-More-Commercial

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Migrating plugins.qgis.org to new server

[Tim Sutton]

Hi All

Just an update quickly from our side….we had some problems with the switch over 
so have left the old site running for now. We will try again tomorrow and post 
a similar notice before we do the witch over. Please resume uploading your 
plugins for now.

Regards

Tim

> On 27 Jan 2020, at 09:32, Tim Sutton  wrote:
> 
> Hi all
> 
> This is just to advise you that we will be migrating the plugins.qgis.org 
>  and planet.qgis.org  web 
> sites to a new server over the next hour or two. We do not expect any 
> downtime of these servers during this migration but we do ask you to hold on 
> uploading any new plugins until I post an update announcement indicating that 
> the new server is online and fully operational.
> 
> During this migration, we will be deploying security updates and a platform 
> upgrade to Django 2.x and Python 3 that was performed by Alessandro Pasotti. 
> Dimas Ciptura also migrated the feed platform used for 
> https://planet.qgis.org  to Django 2.x and Python 
> 3. The plugins web site will also be on it’s own dedicated server now which 
> should hopefully improve responsiveness.
> 
> If you have any problems using / connecting to these servers, please do not 
> hesitate to contact myself and Dimas (in cc) to let us know.
> 
> Thank you 
> 
> Regards
> 
> Tim
> —
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Tim Sutton
> 
> Co-founder: Kartoza
> Ex Project chair: QGIS.org 
> 
> 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 
> 
> I'd love to connect. Here's my calendar link  
> to make finding time easy.
> 

—









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

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

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Are the Projection Problems Fixed in 3.10?

[DelazJ]

Hi,

Le ven. 24 janv. 2020 à 16:57, Mathieu Pellerin  a
écrit :

> It's wise of you not to have your department jump on a .0 release. All
> known (ie reported through filing) protection issues have been resolved.
>
> That said, you should also take on the task of stress testing the latest
> version against your department's workflows and datasets. Unreported issues
> are usually not addressed ;)
>
> +1

> It's especially crucial to do this now as we're 4 weeks away from seeing
> 3.4 being retired in favor of 3.10.
>
> Btw, maybe did I miss it but was there a call for testing, in the "News"
panel?

Gretings,
Harrissou

Cheers
>
> On Fri, Jan 24, 2020, 22:42 C Hamilton  wrote:
>
>> Has 3.10.2-2 been verified to have solved the projection issues. I have
>> been holding off introducing it to our departments until it was fixed. I
>> will also wait for several weeks as well to make sure there isn't some
>> other serious issue.
>>
>> Thanks,
>>
>> Calvin
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Migrating plugins.qgis.org to new server

[Paolo Cavallini]

Great news, thanks Tim!

Il 27/01/20 10:32, Tim Sutton ha scritto:
> Hi all
> 
> This is just to advise you that we will be migrating the
> plugins.qgis.org  and planet.qgis.org
>  web sites to a new server over the next hour or
> two. We do not expect any downtime of these servers during this
> migration but we do ask you to hold on uploading any new plugins until I
> post an update announcement indicating that the new server is online and
> fully operational.
> 
> During this migration, we will be deploying security updates and a
> platform upgrade to Django 2.x and Python 3 that was performed by
> Alessandro Pasotti. Dimas Ciptura also migrated the feed platform used
> for https://planet.qgis.org to Django 2.x and Python 3. The plugins web
> site will also be on it’s own dedicated server now which should
> hopefully improve responsiveness.
> 
> If you have any problems using / connecting to these servers, please do
> not hesitate to contact myself and Dimas (in cc) to let us know.
> 
> Thank you 
> 
> Regards
> 
> Tim
> —
> 
> 
> 
> 
> 
> 
> 
> 
> *Tim Sutton*
> 
> *Co-founder:* Kartoza
> *Ex Project chair:* QGIS.org 
> 
> 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 
> 
> I'd love to connect. Here's my calendar link
>  to make finding time easy.
> 
> 
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> 

-- 
Paolo Cavallini - www.faunalia.eu
QGIS.ORG Chair:
http://planet.qgis.org/planet/user/28/tag/qgis%20board/
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] How to open a QGIS prococessing algorithm dialog in python?

[DelazJ]

Hi,

I have the same needs and I can't find any of these methods in the docs,
neither in https://qgis.org/api/ nor https://qgis.org/pyqgis/master/
Am I missing something?

Regards,
Harrissou

Le lun. 27 janv. 2020 à 07:34, Nyall Dawson  a
écrit :

> On Sat, 25 Jan 2020 at 01:43, Enrico Ferreguti 
> wrote:
> >
> > Hi QGIS developers,
> >
> > I would like to programmatically show a processing algoritm dialog from
> python. I gived a look to processing toolbox and I found that this is
> possible importing and instantiating the class AlgorithmDialog
> [gui/processingToolbox.py][1]
> >
> > from processing.gui.AlgorithmDialog import AlgorithmDialog
> > from qgis.core import QgsApplication
> >
> > alg =
> QgsApplication.processingRegistry().algorithmById('qgis:extractbyattribute')
> > dlg = AlgorithmDialog(alg, False, iface.mainWindow())
> > dlg.show()
> > dlg.exec_()
> >
> > This opens algorithm dialog and let me perform processing computations
> but once closed the dialog window QGIS become instable and crash without
> any message interacting with the user interface.
> >
> > What am I doing wrong? Is there a method to do this in other way?
>
> Yep - there's a built in method which does this for you.
>
> You want either
>
> from qgis.processing import createAlgorithmDialog
> dlg = createAlgorithmDialog('qgis:extractbyattribute', parameters={})
> dlg.exec_()
>
> OR
>
> from qgis.processing import execAlgorithmDialog
> results = execAlgorithmDialog('qgis:extractbyattribute', parameters={})
>
> (check the docs for each for the full details)
>
> In general, try to avoid any "from processing.* " imports -- those are
> all internal details and not considered stable API. Anything in
> "qgis.processing" IS stable and is public API, designed for external
> use.
>
> Nyall
>
>
> >
> > I just posted the question on StackExchange:
> https://gis.stackexchange.com/questions/348542/open-qgis-prococessing-algorithm-dialog-with-python
> >
> > Thanks in advance.
> > Enrico Ferreguti.
> >
> >   [1]:
> https://github.com/qgis/QGIS/blob/276a31439eb95f9cdb1053a6ae2dba3f19fbcece/python/plugins/processing/gui/ProcessingToolbox.py#L262
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Migrating plugins.qgis.org to new server

[Tim Sutton]

Hi all

This is just to advise you that we will be migrating the plugins.qgis.org 
 and planet.qgis.org  web 
sites to a new server over the next hour or two. We do not expect any downtime 
of these servers during this migration but we do ask you to hold on uploading 
any new plugins until I post an update announcement indicating that the new 
server is online and fully operational.

During this migration, we will be deploying security updates and a platform 
upgrade to Django 2.x and Python 3 that was performed by Alessandro Pasotti. 
Dimas Ciptura also migrated the feed platform used for https://planet.qgis.org 
 to Django 2.x and Python 3. The plugins web site 
will also be on it’s own dedicated server now which should hopefully improve 
responsiveness.

If you have any problems using / connecting to these servers, please do not 
hesitate to contact myself and Dimas (in cc) to let us know.

Thank you 

Regards

Tim
—









Tim Sutton

Co-founder: Kartoza
Ex Project chair: QGIS.org

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

I'd love to connect. Here's my calendar link  to 
make finding time easy.

___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Data provider default values and default value clause

[Alessandro Pasotti]

Hi Nyall,

thank you for confirming my worst nightmares :)

Unfortunately, since the data providers are certainly a foundation
component of QGIS, these behavior inconsistencies lead to issues in client
code (GUI/UX mainly but probably also in QgsVectorLayerUtils create
features functions) and I believe we should try hard to find a solution.

Do you think it is a wast of time (because as you mentioned some providers
can't tell the difference between a literal and an expression)?

I've done a PR that does not completely fix all the issues but at least
adds some tests and fixes a few things:
https://github.com/qgis/QGIS/pull/34012



On Mon, Jan 27, 2020 at 7:44 AM Nyall Dawson  wrote:

> On Fri, 24 Jan 2020 at 19:28, Alessandro Pasotti 
> wrote:
> >
>
> > 1. From the docs it seems that the defaultValueClause() should ONLY
> return clauses (like sequences, functions, CURRENT_TIMESTAMP etc.) and
> should NOT return literal defaults.
>
> Correct. However -- not all providers are completely well behaved in
> this regard. Some of these are because of limitations on the provider
> itself, e.g. there is no way to different literal defaults from
> clause-type defaults on the associated backend. When we can't
> differentiate the two, we err on the side of returning a
> possible-literal value from defaultValueClause (and not the reverse
> and accidentally return a non-literal value from defaultValue() ).
>
> > 2. From the docs it seems that defaultValue() should return ONLY literal
> defaults and NOT functions, ::nextval and friends
>
> Correct (and should ALWAYS be the case)
>
> > 3. OGR provider does return the actual client-side calculated value when
> calling defaultValue() ONLY in case of literal defaults and
> CURRENT_TIMESTAMP, CURRENT_DATE and CURRENT_TIME, it returns the clause
> definition in all other cases, is this correct?
>
> Yes - it's deliberate, even thought it slightly violates the above
> answer to (2) in that for this provider we pre-calculate these
> quasi-literal values on the qgis side.
>
> > 4. postgres provider in case the property EvaluateDefaultValues is true
> does something more and send the clause to the server for evaluation,
> returning the calculated value, otherwise it returns the clause definition.
>
> That's correct also, and by design. As per the warnings in the
> defaultValue() docs, defaultValue calls are potentially dangerous to
> make and should only ever be done when creating features (and in that
> situation, only ever called once per field per feature). Otherwise
> when EvaluateDefaultValues is true we run the risk of evaluating
> sequences multiple times for a single feature, causing "gaps" in the
> sequence.
>
> > 5. What to return in case of no defaults? Depending on provider and
> field types, some implementations return a NULL (QVariant()), some others
> return a Python None.
>
> Slight correction: QVariant() != Python NULL. Rather QVariant() ==
> Python None, and QVariant( QVariant::Int ) == Python NULL. The c++ api
> doesn't usually differentiate between the two and QVariant() is more
> commonly used. (And I personally think in 4.0 we should completely
> remove the PyQGIS NULL/QVariant( QVariant::Int ) distinctions -- they
> add much complexity to code without compelling enough benefits).
>
> Short answer: return QVariant() when no default literal exists.
>
> > So, I'm confused about the expected behavior, if the documentation of
> defaultValue() and defaultValueClause() is correct then the provider
> implementations are (at least for some of them) wrong.
>
> Hope that clarifies!
>
> Nyall
>
> >
> > I'd like to hear other developer's opinion before proceeding with a fix
> for the a.m. providers.
> >
> > Thank you in advance!
> >
> > --
> > Alessandro Pasotti
> > w3:   www.itopen.it
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>


-- 
Alessandro Pasotti
w3:   www.itopen.it
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer