Re: [QGIS-Developer] Qgis 2.18 on buster/sid

[Jürgen E . Fischer]

Hi Patrick,

On Thu, 15. Feb 2018 at 15:09:15 +1300, Patrick Dunford wrote:
> Attempting install from the qgis unstable repository fails due to broken
> dependencies

See the note on 
https://qgis.org/en/site/forusers/alldownloads.html#debian-ubuntu.

If you use a unstable distribution the release packages can break, when the
base changes.  You can install from the nightly repositories, which exists for
the release, the long-term release and master - or wait for the next point
release.

Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
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] Qgis 2.18 on buster/sid

[Sebastiaan Couwenberg]

On 02/15/2018 03:09 AM, Patrick Dunford wrote:
> Currently, Qgis 2.18 is not supported on buster/sid. The debian
> repositories provide version 2.14, which appears to be the latest
> release that can be installed on these platforms.

The qgis package in Debian follows the QGIS Long-Term Repo which is also
at 2.14.20.

Next week it will switch to 2.18.17 [0], as will the package in Debian.

[0]
https://qgis.org/en/site/getinvolved/development/roadmap.html#release-schedule

Kind Regards,

Bas
___
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] Qgis 2.18 on buster/sid

[Patrick Dunford]

Good day

Currently, Qgis 2.18 is not supported on buster/sid. The debian 
repositories provide version 2.14, which appears to be the latest 
release that can be installed on these platforms.


Attempting install from the qgis unstable repository fails due to broken 
dependencies


As 2.18 would be supported as a previous LTR can we expect to see it 
supported on buster.


Thanks

___
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] Make Regular Shape Digitizing Toolbar disabled by default?

[Alexandre Neto]

Hi,

It seems that in QGIS 3, the new Regular Shape Digitizing Toolbar is
enabled (visible) by default.

I love the work done for this toolbar, and for people doing lots of
digitizing it looks to be very handy, but I wonder, will that be used by
the majority of people that it "deserves" to be enabled by default?

The advanced digitizing toolbar is even more useful and it's disable by
default, for interface cleaness I guess.

I heard complains about QGIS showing too many buttons, for me this would be
an easy choice to disable

Cheers,

Alex Neto
-- 
Alexandre Neto
-
@AlexNetoGeo
http://sigsemgrilhetas.wordpress.com
http://gisunchained.wordpress.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] Read QgsProject properties

[Gerald Kogler]

2.18

thanks
Gerald

On 14/02/18 02:06, Gerald Kogler wrote:
> 2.x
> 
> On 14/02/18 00:47, Nyall Dawson wrote:
>> On 14 February 2018 at 08:51, Gerald Kogler  wrote:
>>> Hi,
>>>
>>> I'm doing my first explorations into pyqgis and I'm quite amazed,
>>> compliments for the design of the QGIS API!
>>>
>>> So far I recursively read layer groups and layers from QgsProject and
>>> write a json file which I then use to build a layer switcher for Openlayers.
>>>
>>> Now I need to add additional information which is part of .qgs project
>>> file, but I don't have any clue how to access it without parsing the
>>> XML. Everything from .qgs can be read by API methods?
>>>
>>> For example, I want to add to each layer its "Identifiable" info. There
>>> is a XML tag called  in .qgs, how do I get there? I tried with
>>> readEntry() and readListEntry() but without success.
>>>
>>> Or is there any handy reference of all the project properties and how to
>>> read them by the API?
>>
>> The answer depends which QGIS version you're targetting. Are you
>> developing for 2.x or 3.0?
>>
>> 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
> 

___
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] Plugin [1305] Calidad-CAR approval notification.

[noreply]

Plugin Calidad-CAR approval by pcav.
The plugin version "[1305] Calidad-CAR 1.0.3" is now approved
Link: http://plugins.qgis.org/plugins/CalidadCAR/
___
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] Plugin [644] Proportional circles approval notification.

[noreply]

Plugin Proportional circles approval by pcav.
The plugin version "[644] Proportional circles 1.2.7" is now approved
Link: http://plugins.qgis.org/plugins/ProportionalCircles/
___
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] Plugin [1345] FastVersion approval notification.

[noreply]

Plugin FastVersion approval by pcav.
The plugin version "[1345] FastVersion 1.0.0" is now approved
Link: http://plugins.qgis.org/plugins/FastVersion/
___
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] Concerns re UX of new "duplicate features" actions in 2.99

[David Signer]

Dear all  
  
I  agree (and I guess everyone else does), that it's not okay that this feature 
is enabled when the layers are not in editable mode. I already started to fix 
that, but because of time I had to decide to finish it next week.  
  
Anyway, there is still the question, where it should appear. IMHO it should be 
everywhere, where you can add and delete features. If it's a MapTool it could 
be there as well, I think. I'll have to think about that.  
  
Thanks for your inputs  
Dave  
  


  
-  


David Signer  


Programmer OPENGIS.CH  


Wülflingerstrasse 213  


CH - 8408  Winterthur  


+ 41 (0) 78 766 13 03  


-  


  

___
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] Split parts tool creates invalid polygons

[Anita Graser]

Hi Raymond,

On Tue, Feb 13, 2018 at 10:43 PM, Raymond Nijssen 
wrote:

> Hi Anita,
> Tried what you said but cannot reproduce it. This might depend a lot on
> what shape you draw and how/where you cut it. What does your validation
> error say?
>

​Strange, I tried this a couple of times yesterday before sending the email
... but today I don't get invalid features after moving the vertices apart.
​

​Sorry for the noise!

Anita

​
___
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] Bumping Qt to 5.9 on Travis

[Alessandro Pasotti]

On Wed, Feb 14, 2018 at 4:40 PM, Denis Rouzaud 
wrote:

> Hi all,
>
> I am wondering which versions of the base libraries we should build QGIS
> upon on Travis. Read Qt, PyQt, SIP, etc.
>
> Today the Docker image for the dependencies (qgis/qgis3-build-deps) is
> based on Ubuntu 16.04 and ships Qt 5.5.
> While this sounds reasonable for testing, it is not suitable for building
> and publishing an image of QGIS or building the Python API doc.
>
> So, I'd like to bump the Qt version on Travis to 5.9 (and SIP to 4.19.7).
>
> Another advantage is that we will be able to build 3D on Travis too.
>
> But, there won't be any error if one pushes changes only possible with
> newest version of Qt and only Jürgen will notice it from the nightly builds.
>
> Another approach would be to fire two builds on Travis (one on 5.5 and one
> on latest). It would be pretty straightforward, but I guess that will be
> slowing down the build (am I right?).
>
> Let me know your thoughts,
>
> Denis
>


I'd just drop 5.5 and stay with 5.9 + latest sip, thanks for taking care of
this!


-- 
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

[QGIS-Developer] Bumping Qt to 5.9 on Travis

[Denis Rouzaud]

Hi all,

I am wondering which versions of the base libraries we should build QGIS
upon on Travis. Read Qt, PyQt, SIP, etc.

Today the Docker image for the dependencies (qgis/qgis3-build-deps) is
based on Ubuntu 16.04 and ships Qt 5.5.
While this sounds reasonable for testing, it is not suitable for building
and publishing an image of QGIS or building the Python API doc.

So, I'd like to bump the Qt version on Travis to 5.9 (and SIP to 4.19.7).

Another advantage is that we will be able to build 3D on Travis too.

But, there won't be any error if one pushes changes only possible with
newest version of Qt and only Jürgen will notice it from the nightly builds.

Another approach would be to fire two builds on Travis (one on 5.5 and one
on latest). It would be pretty straightforward, but I guess that will be
slowing down the build (am I right?).

Let me know your thoughts,

Denis
___
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] Python QgsProcessingLagorithm.parameterAsSink return values

[G. Allegri]

Ok, thanks.

2018-02-14 15:41 GMT+01:00 Salvatore Larosa :

> Sorry...
>
> http://python.qgis.org/api/
>
> On Wed, Feb 14, 2018 at 3:40 PM, G. Allegri  wrote:
>
>> That's what I thought Salvatore, but I can only see the text "QGIS Python
>> Documentation" on a blank page.
>> I guess it's currently broken...
>>
>> 2018-02-14 15:38 GMT+01:00 Salvatore Larosa :
>>
>>> On Wed, Feb 14, 2018 at 3:33 PM, G. Allegri  wrote:
>>>
 Thanks Nyall and Salvatore.
 I missed the SIP_OUT specifier of the destinationIdentifier parameter.

 Some days ago I saw the PyQGIS API docs from a link by Nyall, but I
 can't find it now. Where are they?

>>>
>>> http://python.qgis.org
>>>
>>> Ciao.
>>>
>>>
>>> --
>>> Salvatore Larosa
>>> linkedIn: http://linkedin.com/in/larosasalvatore
>>> twitter: @lrssvt
>>> skype: s.larosa
>>> IRC: lrssvt on freenode
>>>
>>
>>
>
>
> --
> Salvatore Larosa
> linkedIn: http://linkedin.com/in/larosasalvatore
> twitter: @lrssvt
> skype: s.larosa
> IRC: lrssvt on freenode
>
___
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] Python QgsProcessingLagorithm.parameterAsSink return values

[Salvatore Larosa]

Sorry...

http://python.qgis.org/api/

On Wed, Feb 14, 2018 at 3:40 PM, G. Allegri  wrote:

> That's what I thought Salvatore, but I can only see the text "QGIS Python
> Documentation" on a blank page.
> I guess it's currently broken...
>
> 2018-02-14 15:38 GMT+01:00 Salvatore Larosa :
>
>> On Wed, Feb 14, 2018 at 3:33 PM, G. Allegri  wrote:
>>
>>> Thanks Nyall and Salvatore.
>>> I missed the SIP_OUT specifier of the destinationIdentifier parameter.
>>>
>>> Some days ago I saw the PyQGIS API docs from a link by Nyall, but I
>>> can't find it now. Where are they?
>>>
>>
>> http://python.qgis.org
>>
>> Ciao.
>>
>>
>> --
>> Salvatore Larosa
>> linkedIn: http://linkedin.com/in/larosasalvatore
>> twitter: @lrssvt
>> skype: s.larosa
>> IRC: lrssvt on freenode
>>
>
>


-- 
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
twitter: @lrssvt
skype: s.larosa
IRC: lrssvt on freenode
___
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] Python QgsProcessingLagorithm.parameterAsSink return values

[G. Allegri]

That's what I thought Salvatore, but I can only see the text "QGIS Python
Documentation" on a blank page.
I guess it's currently broken...

2018-02-14 15:38 GMT+01:00 Salvatore Larosa :

> On Wed, Feb 14, 2018 at 3:33 PM, G. Allegri  wrote:
>
>> Thanks Nyall and Salvatore.
>> I missed the SIP_OUT specifier of the destinationIdentifier parameter.
>>
>> Some days ago I saw the PyQGIS API docs from a link by Nyall, but I can't
>> find it now. Where are they?
>>
>
> http://python.qgis.org
>
> Ciao.
>
>
> --
> Salvatore Larosa
> linkedIn: http://linkedin.com/in/larosasalvatore
> twitter: @lrssvt
> skype: s.larosa
> IRC: lrssvt on freenode
>
___
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] Python QgsProcessingLagorithm.parameterAsSink return values

[Salvatore Larosa]

On Wed, Feb 14, 2018 at 3:33 PM, G. Allegri  wrote:

> Thanks Nyall and Salvatore.
> I missed the SIP_OUT specifier of the destinationIdentifier parameter.
>
> Some days ago I saw the PyQGIS API docs from a link by Nyall, but I can't
> find it now. Where are they?
>

http://python.qgis.org

Ciao.


-- 
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
twitter: @lrssvt
skype: s.larosa
IRC: lrssvt on freenode
___
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] Python QgsProcessingLagorithm.parameterAsSink return values

[G. Allegri]

Thanks Nyall and Salvatore.
I missed the SIP_OUT specifier of the destinationIdentifier parameter.

Some days ago I saw the PyQGIS API docs from a link by Nyall, but I can't
find it now. Where are they?

Giovanni

2018-02-14 15:13 GMT+01:00 Salvatore Larosa :

> Hi Giovanni,
>
> On Wed, Feb 14, 2018 at 2:13 PM, G. Allegri  wrote:
>
>> I'm trying to follow the code that produces the two return values from
>> QgsProcessingLagorithm.parameterAsSink in Python. I can't find where the
>> sip interface (or whatever) changes the API return value
>> 
>> to the two returned values "sink" and "dest_id".
>>
>> Where does it happen?
>>
>
> it happens here: https://github.com/qgis/QGIS/blob/master/src/core/
> processing/qgsprocessingalgorithm.h#L593
>
>
>> What does the second parameter (destination id) refer to?
>>
>
> the destinationIdentifier string namely the map layer id:
> https://github.com/qgis/QGIS/blob/master/src/core/processing/
> qgsprocessingalgorithm.h#L588
>
> --
> Salvatore Larosa
> linkedIn: http://linkedin.com/in/larosasalvatore
> twitter: @lrssvt
> skype: s.larosa
> IRC: lrssvt on freenode
>
___
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] Concerns re UX of new "duplicate features" actions in 2.99

[Denis Rouzaud]

Le mar. 13 févr. 2018 à 23:34, Nyall Dawson  a
écrit :

> Hi all,
>
> Just wanted to raise discussion about a concern I have with the new
> "duplicate feature" / "duplicate feature and redigitize" actions which
> have been added for 3.0.
>
> While I like the functionality, I believe we should re-think the UX of
> how it is exposed in the QGIS interface.
>
> Currently, it's implemented as a "feature action", so appears in
> numerous places throughout the QGIS UI, including:
> - the actions drop down submenu on the toolbar
> - within the right click menu for the "identify tool"
> - under the "actions" heading in the identify results dock for a feature
> - in a menu bar at the top of the form shown after adding a new feature
> - as an entry within the right click menu in the attribute table
>
> So my initial concern is that exposing it in all these places is
> overkill and far too prominent for this operation. But my deeper
> concern is that these actions skip the edit buffer and directly alter
> layers in place, even when those layers are not made editable
> (https://issues.qgis.org/issues/17852). So now we've got a menu item
> exposed in all these places which causes permanent changes to a layer,
> including in places which are not associated with editing at all (e.g.
> the identify tool right click menu).
>
> I'm also unsure what the actions would do in some contexts - e.g. if I
> create a new feature and then select "duplicate feature" in the popup
> form *before* this feature has even be finalized, what does it mean?
>
> I'd very much like to see this re-thought before our final release,
> and exposed in a more standard way via the advanced digitizing
> toolbar.


I think it make some sense to design this as a map tool (if possible).
We don't have a simplify action, it's a map tool.

It could still be possible to add a custom action which will use the API to
duplicate the feature (if one really wants this feature as an action in the
form or attribute table or identify menu).

Enhancing the action API to define action on editable layers only sounds
like a good addition too, but I think is not sufficient here (taking the
simplify map tool as example).

My 2 cts.
___
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] Plugin [609] Temporal/Spectral Profile Tool approval notification.

[noreply]

Plugin Temporal/Spectral Profile Tool approval by pcav.
The plugin version "[609] Temporal/Spectral Profile Tool 2.0.0" is now approved
Link: http://plugins.qgis.org/plugins/temporalprofiletool/
___
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] Python QgsProcessingLagorithm.parameterAsSink return values

[Salvatore Larosa]

Hi Giovanni,

On Wed, Feb 14, 2018 at 2:13 PM, G. Allegri  wrote:

> I'm trying to follow the code that produces the two return values from
> QgsProcessingLagorithm.parameterAsSink in Python. I can't find where the
> sip interface (or whatever) changes the API return value
> 
> to the two returned values "sink" and "dest_id".
>
> Where does it happen?
>

it happens here:
https://github.com/qgis/QGIS/blob/master/src/core/processing/qgsprocessingalgorithm.h#L593


> What does the second parameter (destination id) refer to?
>

the destinationIdentifier string namely the map layer id:
https://github.com/qgis/QGIS/blob/master/src/core/processing/qgsprocessingalgorithm.h#L588

-- 
Salvatore Larosa
linkedIn: http://linkedin.com/in/larosasalvatore
twitter: @lrssvt
skype: s.larosa
IRC: lrssvt on freenode
___
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] Python QgsProcessingLagorithm.parameterAsSink return values

[Nyall Dawson]

On 15 February 2018 at 00:13, G. Allegri  wrote:
> I'm trying to follow the code that produces the two return values from
> QgsProcessingLagorithm.parameterAsSink in Python. I can't find where the sip
> interface (or whatever) changes the API return value to the two returned
> values "sink" and "dest_id".
>
> Where does it happen?

This is the "destinationIdentifier" argument from the c++ API - sip
automatically converts arguments passed by reference like this into
return values. The PyQGIS docs show it a bit clearer.

> What does the second parameter (destination id) refer to?

Per the docs: "The destinationIdentifier argument will be set to a
string which can be used to retrieve the layer corresponding to the
sink,". It's a unique text identifier which processing uses to later
retrieve the result (and to pass on to following algorithms in a
model). The important thing here is that when your algorithm returns
its result dictionary, it should contain an entry for the output with
the corresponding destinationIdentifier as the value.

Here's a good example:

making the sink:
https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/qgis/CheckValidity.py#L126

including it in the results:
https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/qgis/CheckValidity.py#L196

Nyall

>
> Thanks,
> Giovanni
>
>
>
> ___
> 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] When is Qt updated for the Windows releases?

[Jürgen E . Fischer]

Hi Nyall,

On Wed, 14. Feb 2018 at 23:59:07 +1100, Nyall Dawson wrote:
> > But if we update I'd do them with one of our point releases so that the new
> > release is build with then available Qt - the next nightlies would also pick
> > them up.  Otherwise we'd have the release packages using a newer Qt then the
> > one they were built with.
 
> That's all fair enough. Does your no-upgrade plan include Qt bug fix
> releases? E.g. 5.9.4?

If there was a plan, it would include it.  Now it's simply only done when there
is a significant need to do it (eg. QGIS doesn't build without it, we have to
support older version of Qt just to suit OSGeo4W or when it enables something
important; blurry yes).  That also applies to many other things in OSGeo4W
(except for QGIS, GRASS and GDAL).


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
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] Python QgsProcessingLagorithm.parameterAsSink return values

[G. Allegri]

I'm trying to follow the code that produces the two return values from
QgsProcessingLagorithm.parameterAsSink in Python. I can't find where the
sip interface (or whatever) changes the API return value

to the two returned values "sink" and "dest_id".

Where does it happen?
What does the second parameter (destination id) refer to?

Thanks,
Giovanni
___
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] When is Qt updated for the Windows releases?

[Nyall Dawson]

On 14 February 2018 at 23:35, Jürgen E. Fischer  wrote:
> Hi Nyall,
>
> On Wed, 14. Feb 2018 at 21:43:35 +1100, Nyall Dawson wrote:
>> The point releases we should probably time just after our monthly release so
>> that the upgrade gets a full month of testing and there's plenty of time to
>> rollback if necessary. Bring on the upgrades I say!
>
> With point releases I was refering to our monthly release.  I don't plan to do
> any Qt updates unless we require them for new stuff (like 3D; which triggered
> the update from 5.7 to 5.9).
>
> But if we update I'd do them with one of our point releases so that the new
> release is build with then available Qt - the next nightlies would also pick
> them up.  Otherwise we'd have the release packages using a newer Qt then the
> one they were built with.

That's all fair enough. Does your no-upgrade plan include Qt bug fix
releases? E.g. 5.9.4?

(Please understand I'm not asking you to do work here... I just want
to fully understand the plans).

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] When is Qt updated for the Windows releases?

[Jürgen E . Fischer]

Hi Nyall,

On Wed, 14. Feb 2018 at 21:43:35 +1100, Nyall Dawson wrote:
> The point releases we should probably time just after our monthly release so
> that the upgrade gets a full month of testing and there's plenty of time to
> rollback if necessary. Bring on the upgrades I say!

With point releases I was refering to our monthly release.  I don't plan to do
any Qt updates unless we require them for new stuff (like 3D; which triggered
the update from 5.7 to 5.9).

But if we update I'd do them with one of our point releases so that the new
release is build with then available Qt - the next nightlies would also pick
them up.  Otherwise we'd have the release packages using a newer Qt then the
one they were built with.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
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] When is Qt updated for the Windows releases?

[Nyall Dawson]

On 14 February 2018 at 20:15, Jürgen E. Fischer  wrote:
> Hi Nyall,
>
> On Wed, 14. Feb 2018 at 19:30:49 +1100, Nyall Dawson wrote:
>> But what about dev releases? E.g. if we wanted to introduce 5.10 for 3.2 on
>> Windows, then switching over the dev builds alone isn't possible, right?
>
> Correct.
>
>
>> We'd have to update the Qt library for all builds (3.0.1 and above) and the
>> dev builds simultaneously. I guess we could theoretically time an upgrade to
>> occur just before a stable release (i.e. right before 3.2.0, when no more
>> 3.0.x builds will be released), but that sounds potentially dangerous.
>
> If you're after avoiding to do extra builds any point release should do.  I
> don't see a big issue - we'd just publish a new Qt on a point release along
> with the new qgis builds that already use them - as long QGIS is the only
> dependant.

I'm personally fine with this. I mean, generally Qt upgrades are
painless and don't introduce new bugs (especially the point releases).
The situation with 5.10 is an obvious exception - but I don't recall
ever having an issue like this in the past.  (Oh wait, let's add 5.6
and its QVariant mess to that list too... 5.6 was the worst Qt release
I've ever seen.)

>> >> So I'd hate to see the Windows builds locked to 5.9 indefinitely.
>
>> > Windows is not the only platform.  Debian unstable is also at 5.9
>> > currently, buster/testing 5.9,  stretch/stable has 5.7 (so we build without
>> > 3D there).  bionic (next ubuntu lts) also has 5.9.
>
>> Oh yeah, linux distros are a totally different matter and I'm not suggesting
>> any change there. I'm just curious about what the exact situation is with the
>> Windows builds.
>
> Why does that matter?  If the code builds with 5.9 and 5.10 then there's no
> QGIS issue.

Like I said above, I'm all in favour of upgrading Qt (I'd love to have
a windows 5.10.1 build). Manpower aside, I don't see any reason why we
wouldn't want the patch releases used as soon as they are available.
The point releases we should probably time just after our monthly
release so that the upgrade gets a full month of testing and there's
plenty of time to rollback if necessary. Bring on the upgrades I say!

This whole thread was just me trying to understand the
process/implications of the Windows build/release process.

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

[QGIS-Developer] Plugin [1143] PostGIS Sampling Tool approval notification.

[noreply]

Plugin PostGIS Sampling Tool approval by pcav.
The plugin version "[1143] PostGIS Sampling Tool 1.4.1" is now approved
Link: http://plugins.qgis.org/plugins/postgis_sampling_tool/
___
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] When is Qt updated for the Windows releases?

[Jürgen E . Fischer]

Hi Nyall,

On Wed, 14. Feb 2018 at 19:30:49 +1100, Nyall Dawson wrote:
> But what about dev releases? E.g. if we wanted to introduce 5.10 for 3.2 on
> Windows, then switching over the dev builds alone isn't possible, right?

Correct.


> We'd have to update the Qt library for all builds (3.0.1 and above) and the
> dev builds simultaneously. I guess we could theoretically time an upgrade to
> occur just before a stable release (i.e. right before 3.2.0, when no more
> 3.0.x builds will be released), but that sounds potentially dangerous.

If you're after avoiding to do extra builds any point release should do.  I
don't see a big issue - we'd just publish a new Qt on a point release along
with the new qgis builds that already use them - as long QGIS is the only
dependant.

 
> >> So I'd hate to see the Windows builds locked to 5.9 indefinitely.

> > Windows is not the only platform.  Debian unstable is also at 5.9
> > currently, buster/testing 5.9,  stretch/stable has 5.7 (so we build without
> > 3D there).  bionic (next ubuntu lts) also has 5.9.

> Oh yeah, linux distros are a totally different matter and I'm not suggesting
> any change there. I'm just curious about what the exact situation is with the
> Windows builds.

Why does that matter?  If the code builds with 5.9 and 5.10 then there's no
QGIS issue.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
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] Concerns re UX of new "duplicate features" actions in 2.99

[Régis Haubourg]

Hi,
I totally agree. BTW, having a generic option to display some actions only
in edit mode would be a nice addition for 3.2!
Regards
Régis

Le 14 févr. 2018 04:34, "Nyall Dawson"  a écrit :

Hi all,

Just wanted to raise discussion about a concern I have with the new
"duplicate feature" / "duplicate feature and redigitize" actions which
have been added for 3.0.

While I like the functionality, I believe we should re-think the UX of
how it is exposed in the QGIS interface.

Currently, it's implemented as a "feature action", so appears in
numerous places throughout the QGIS UI, including:
- the actions drop down submenu on the toolbar
- within the right click menu for the "identify tool"
- under the "actions" heading in the identify results dock for a feature
- in a menu bar at the top of the form shown after adding a new feature
- as an entry within the right click menu in the attribute table

So my initial concern is that exposing it in all these places is
overkill and far too prominent for this operation. But my deeper
concern is that these actions skip the edit buffer and directly alter
layers in place, even when those layers are not made editable
(https://issues.qgis.org/issues/17852). So now we've got a menu item
exposed in all these places which causes permanent changes to a layer,
including in places which are not associated with editing at all (e.g.
the identify tool right click menu).

I'm also unsure what the actions would do in some contexts - e.g. if I
create a new feature and then select "duplicate feature" in the popup
form *before* this feature has even be finalized, what does it mean?

I'd very much like to see this re-thought before our final release,
and exposed in a more standard way via the advanced digitizing
toolbar.

Thoughts?

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
___
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] When is Qt updated for the Windows releases?

[Nyall Dawson]

Thanks for the quick confirmation Jürgen!

On 14 February 2018 at 19:07, Jürgen E. Fischer  wrote:
>
>> If this is the case, it means that upgrading our qt version at some stage to
>> 5.9.4 (or 5.10.1) would also affect patch releases, right? E.g. updating to
>> 5.10.1 for a future 3.2 release would mean that the next 3.0.x build would
>> also jump up to 5.10.1.
>
> As 3.0 will be replaced with 3.2 once it's there (3.4 will be the next LTR), 
> so
> that's not the actual case.  But yes, switching to a newer version for Qt5 
> will
> require to rebuild everything that uses Qt5 (currently that's - not counting
> PyQt5 - only QGIS 3.x).

But what about dev releases? E.g. if we wanted to introduce 5.10 for
3.2 on Windows, then switching over the dev builds alone isn't
possible, right? We'd have to update the Qt library for all builds
(3.0.1 and above) and the dev builds simultaneously. I guess we could
theoretically time an upgrade to occur just before a stable release
(i.e. right before 3.2.0, when no more 3.0.x builds will be released),
but that sounds potentially dangerous.


>> So I'd hate to see the Windows builds locked to 5.9 indefinitely.
>
> Windows is not the only platform.  Debian unstable is also at 5.9 currently,
> buster/testing 5.9,  stretch/stable has 5.7 (so we build without 3D there).
> bionic (next ubuntu lts) also has 5.9.

Oh yeah, linux distros are a totally different matter and I'm not
suggesting any change there. I'm just curious about what the exact
situation is with the Windows builds.

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] When is Qt updated for the Windows releases?

[Jürgen E . Fischer]

Hi Nyall,

On Wed, 14. Feb 2018 at 14:14:10 +1000, Nyall Dawson wrote:
> If my understanding is correct, the osgeo4w architecture (and correspondingly
> the windows release builds) only currently supports a single version of qt 5
> (and a single qt 4 version).

Correct.


> If this is the case, it means that upgrading our qt version at some stage to
> 5.9.4 (or 5.10.1) would also affect patch releases, right? E.g. updating to
> 5.10.1 for a future 3.2 release would mean that the next 3.0.x build would
> also jump up to 5.10.1.

As 3.0 will be replaced with 3.2 once it's there (3.4 will be the next LTR), so
that's not the actual case.  But yes, switching to a newer version for Qt5 will
require to rebuild everything that uses Qt5 (currently that's - not counting
PyQt5 - only QGIS 3.x).


> Is this interpretation correct? Do we consider this safe to do in a patch
> mid-way through a stable release? And if not, does it mean we're effectively
> stuck with the current version of Qt throughout the life of 3.x?

Not necessarily, but we'd have to update all 3.x to be able to build & run with
the Qt5 we have (ie. 3.4 and 3.x w/ x>4).


> So I'd hate to see the Windows builds locked to 5.9 indefinitely.

Windows is not the only platform.  Debian unstable is also at 5.9 currently,
buster/testing 5.9,  stretch/stable has 5.7 (so we build without 3D there).
bionic (next ubuntu lts) also has 5.9.


Jürgen

-- 
Jürgen E. Fischer   norBIT GmbH Tel. +49-4931-918175-31
Dipl.-Inf. (FH) Rheinstraße 13  Fax. +49-4931-918175-50
Software Engineer   D-26506 Norden http://www.norbit.de
QGIS release manager (PSC)  GermanyIRC: jef on FreeNode


signature.asc
Description: PGP signature
___
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