[QGIS-Developer] Plugin [1456] EO Time Series Viewer approval notification.

2020-04-09 Thread noreply

Plugin EO Time Series Viewer approval by pcav.
The plugin version "[1456] EO Time Series Viewer 1.12.20200410T022734.master" 
is now approved
Link: http://plugins.qgis.org/plugins/timeseriesviewerplugin/
___
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-psc] Position on Qt wrt The QT Company announcements

2020-04-09 Thread Nyall Dawson
On Fri, 10 Apr 2020 at 06:45, Even Rouault  wrote:

> But whatever the outcome of the apparently cool discussions within the board 
> of the KDE Free Qt foundation between the KDE e.v and QT Company 
> representatives, I don't think a statement of support from QGIS.org to the 
> open source side of the QT project would hurt.

+1 to this. I've already had one customer contact me concerned about
this news, and wondering what it meant for QGIS. A blog post showing
our support for the open-source/KDE side of Qt + stating the impact on
QGIS would be helpful all round I think.

My 2c (regarding the impact on QGIS, if this went ahead): Honestly,
it's likely to be minimal. Because:

1. Qt Company really do very little maintenance on the parts of Qt the
QGIS desktop/server applications use. The changelogs for the
core/gui/widget libraries for new Qt releases + patches are very
minimal, and bug reports filed against these components get basically
no attention from Qt Company. Their priorities over the recent years
have been elsewhere (in the embedded + automotive + mobile space), and
all the interesting changes coming into core/gui/widgets are coming
from elsewhere (e.g. KDAB were/are behind the whole qt 3d framework,
and they've already stated that they'd follow a community driven fork
[1])

2. Despite one initial reply on the KDE list stating that there's
insufficient manpower to support a community fork [2], the rest of the
discussion on the qt mailing list is quite positive about the
community's ability to maintain a fork

3. A community fork would likely end up being great for Qt (my
opinion). It certainly had a huge positive impact on
OpenOffice/LibreOffice. Qt is currently REALLY difficult for new
contributors to contribute to, so it's possible a community driven
fork with more of a collaborative focus would see a bunch of new
contributors coming in. Certainly the talk on the Qt mailing lists
over the last 1-2 years has shown a huge amount of dissatisfaction
with the leadership and direction taken by the Qt Company, and
complaints about how out of touch they are with their user's needs.

4. Our releases are generally quite slow to adopt new Qt library
versions anyway, so a 12 month delay from a new release is likely to
have minimal impact (e.g. our Windows builds are based on a version of
qt which is nearly 2 years old). It'd be nice if we updated more
often, but the current situation is reflective of the fact that
there's no particular compelling reasons to upgrade to a more recent
Qt version! Let me rephrase that for emphasis: **in the last 2 years,
there hasn't been ANY change made in Qt which would have had big
enough impact on QGIS users to warrant the effort required for the
package update**.   (Compare that with how far QGIS has come in the
same time frame... I certainly wouldn't recommend that ANYONE even
THINK of running QGIS 3.2 today!!!)

The biggest impact it would have would be on the Qfield and Input
mobile apps, which rely heavily on QML. Qt company **is** actively
working on QML, and these updates are useful -- partly because QML
still has huge feature gaps preventing it being used as a real
alternative to Qt widgets, and partly because it's still buggy and
they are still fixing their messes ;).

Nyall





1. https://mail.kde.org/pipermail/kde-community/2020q2/006105.html
2. https://mail.kde.org/pipermail/kde-community/2020q2/006099.html



> http://www.spatialys.com
>
> ___
> Qgis-psc mailing list
> qgis-...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-psc
___
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-psc] Position on Qt wrt The QT Company announcements

2020-04-09 Thread Even Rouault
On jeudi 9 avril 2020 21:30:02 CEST Martin Dobias wrote:
> Hi Vincent
> 
> On Thu, Apr 9, 2020, 18:32 Vincent Picavet (ml) 
> 
> wrote:
> > Hi all, PSC,
> > 
> > Olaf Schmidt-Wishhöfer from KDE project has made a statement yesterday
> > about a
> > really concerning situation regarding the OpenSource state of Qt.
> > 
> > https://mail.kde.org/pipermail/kde-community/2020q2/006098.html
> 
> The Qt Company has published a short blog post today saying that those
> discussions do not reflect their views and plans:
> https://www.qt.io/blog/qt-and-open-source
> 
> So maybe better to wait for some clarifications to make sure we are not
> rushing to spread claims that may not be correct...?

That's true, but it seems The QT Company has been lately testing the open 
source side of the 
QT community, with this recent event and the announcement in January to keep 
the LTS 
branches closed for 12 months, to apparently try getting more concessions in 
the contract 
with the KDE Free Qt foundation.
And even in their above correction post, they remain super vague and don't 
answer the 
points that would be wrong in Olaf Schmidt-Wishhöfer post

I doubt that the QT company would decide to go for the plan of delaying the 
open source 
version by 12 months, as the consequence (the last version of QT being 
potentially released 
as BSD) could actually quite harm their own business by allowing other 
commercial forks!

But whatever the outcome of the apparently cool discussions within the board of 
the KDE 
Free Qt foundation between the KDE e.v and QT Company representatives, I don't 
think a 
statement of support from QGIS.org to the open source side of the QT project 
would hurt.

As far as which body to officially support, this is a bit difficult. As the 
board of the KDE Free 
Qt foundation is made of 2 representatives from KDE e.V and 2 from The QT 
Company, it 
seems difficult to imagine that it would continue to exist as such, or be still 
relevant, in the 
event The QT company would execute their 12-month-delay plan. And before 
financially 
supporting the KDE Free Qt foundation or whatever other body would represent 
best the 
interests of a FOSS QT (I guess a new body gathering together KDE, KDAB and all 
other 
parties would be more relevant in the event a FOSS QT fork would be needed), we 
should 
probably have a look at its current finances/budget (from a quick search, 
couldn't find one 
regarding KDE Free Qt foundation, apart from the 200 000 KRO founding capital 
mentionned 
in their status [1])

In the discussion thread, I see a message from the KDE e.V vice president ([2]) 
opening 
discussion lines.

Even

[1] https://kde.org/community/whatiskde/KDEFreeQt_Statutes_09_final.pdf
[2] https://mail.kde.org/pipermail/kde-community/2020q2/006107.html

-- 
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] [Qgis-psc] Position on Qt wrt The QT Company announcements

2020-04-09 Thread Martin Dobias
Hi Vincent

On Thu, Apr 9, 2020, 18:32 Vincent Picavet (ml) 
wrote:

> Hi all, PSC,
>
> Olaf Schmidt-Wishhöfer from KDE project has made a statement yesterday
> about a
> really concerning situation regarding the OpenSource state of Qt.
>
> https://mail.kde.org/pipermail/kde-community/2020q2/006098.html


The Qt Company has published a short blog post today saying that those
discussions do not reflect their views and plans:
https://www.qt.io/blog/qt-and-open-source

So maybe better to wait for some clarifications to make sure we are not
rushing to spread claims that may not be correct...?

Cheers
Martin
___
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] Position on Qt wrt The QT Company announcements

2020-04-09 Thread Andreas Neumann

Hi Paolo,

We didn't have any contact with the QT Company, but with KDAB in 
Germany, which is a different company that does QT development, as far 
as I know.


Andreas

Am 09.04.20 um 19:27 schrieb Paolo Cavallini:

Hi Vincent,

Il 09/04/20 18:25, Vincent Picavet (ml) ha scritto:


Olaf Schmidt-Wishhöfer from KDE project has made a statement yesterday about a
really concerning situation regarding the OpenSource state of Qt.

https://mail.kde.org/pipermail/kde-community/2020q2/006098.html

TL;DR : using the argument of COVID-19 crisis, The Qt Company wants to restrict
a lot the opensource version of Qt, with a 12 months publishing delay even for
security patches.

Relations between The Qt Company and the OpenSource community degraded vastly
over the last month, and what was a balanced governance and economical situation
tends towards a stuck situation, with all OpenSource Qt users at risk of being
deeply affected.

The KDE Free Qt foundation is currently the organization defending free and
opensource access to Qt.

https://kde.org/community/whatiskde/kdefreeqtfoundation.php

Given that QGIS is probably one of the most distributed Qt-based software
solution in the world, I think that we should take position in this situation.

My Opinion is that QGIS.org should clearly express a full support to the KDE
Free Qt Foundation, and send them an official public message.

I also think that if the situation evolves to a point where a Qt Fork becomes
the only viable solution to continue to have a free and opensource Qt project
with a balanced and open governance, then QGIS.org should also contribute to
financing the KDE Free Qt foundation yearly, so that they are able to hire
maintainers for the library.

I think that these points are decisions to be made by the PSC, and that there is
a certain urgency to do it.

thanks a lot for the detailed report. As you descripe it the situation
is surely concerning us. Please those who had already contacts with Qt
and who follows the situation closely give their opinion.
Cheers.

___
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] Position on Qt wrt The QT Company announcements

2020-04-09 Thread Paolo Cavallini
Hi Vincent,

Il 09/04/20 18:25, Vincent Picavet (ml) ha scritto:

> Olaf Schmidt-Wishhöfer from KDE project has made a statement yesterday about a
> really concerning situation regarding the OpenSource state of Qt.
> 
> https://mail.kde.org/pipermail/kde-community/2020q2/006098.html
> 
> TL;DR : using the argument of COVID-19 crisis, The Qt Company wants to 
> restrict
> a lot the opensource version of Qt, with a 12 months publishing delay even for
> security patches.
> 
> Relations between The Qt Company and the OpenSource community degraded vastly
> over the last month, and what was a balanced governance and economical 
> situation
> tends towards a stuck situation, with all OpenSource Qt users at risk of being
> deeply affected.
> 
> The KDE Free Qt foundation is currently the organization defending free and
> opensource access to Qt.
> 
> https://kde.org/community/whatiskde/kdefreeqtfoundation.php
> 
> Given that QGIS is probably one of the most distributed Qt-based software
> solution in the world, I think that we should take position in this situation.
> 
> My Opinion is that QGIS.org should clearly express a full support to the KDE
> Free Qt Foundation, and send them an official public message.
> 
> I also think that if the situation evolves to a point where a Qt Fork becomes
> the only viable solution to continue to have a free and opensource Qt project
> with a balanced and open governance, then QGIS.org should also contribute to
> financing the KDE Free Qt foundation yearly, so that they are able to hire
> maintainers for the library.
> 
> I think that these points are decisions to be made by the PSC, and that there 
> is
> a certain urgency to do it.

thanks a lot for the detailed report. As you descripe it the situation
is surely concerning us. Please those who had already contacts with Qt
and who follows the situation closely give their opinion.
Cheers.
-- 
Paolo Cavallini - QGIS.ORG Chair
www.faunalia.eu:
training, support, development on QGIS, PostGIS and more
___
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 [2026] Multiple Layers Edit approval notification.

2020-04-09 Thread noreply

Plugin Multiple Layers Edit approval by pcav.
The plugin version "[2026] Multiple Layers Edit 0.31" is now approved
Link: http://plugins.qgis.org/plugins/multiple_layers_edit/
___
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] Position on Qt wrt The QT Company announcements

2020-04-09 Thread Vincent Picavet (ml)
Hi all, PSC,

Olaf Schmidt-Wishhöfer from KDE project has made a statement yesterday about a
really concerning situation regarding the OpenSource state of Qt.

https://mail.kde.org/pipermail/kde-community/2020q2/006098.html

TL;DR : using the argument of COVID-19 crisis, The Qt Company wants to restrict
a lot the opensource version of Qt, with a 12 months publishing delay even for
security patches.


Relations between The Qt Company and the OpenSource community degraded vastly
over the last month, and what was a balanced governance and economical situation
tends towards a stuck situation, with all OpenSource Qt users at risk of being
deeply affected.

The KDE Free Qt foundation is currently the organization defending free and
opensource access to Qt.

https://kde.org/community/whatiskde/kdefreeqtfoundation.php

Given that QGIS is probably one of the most distributed Qt-based software
solution in the world, I think that we should take position in this situation.

My Opinion is that QGIS.org should clearly express a full support to the KDE
Free Qt Foundation, and send them an official public message.

I also think that if the situation evolves to a point where a Qt Fork becomes
the only viable solution to continue to have a free and opensource Qt project
with a balanced and open governance, then QGIS.org should also contribute to
financing the KDE Free Qt foundation yearly, so that they are able to hire
maintainers for the library.

I think that these points are decisions to be made by the PSC, and that there is
a certain urgency to do it.

Best regards,
Vincent Picavet
___
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] libprotobuf-lite.dll dependency QGIS-dev osgeo4w?

2020-04-09 Thread Richard Duivenvoorde
Hi,

I have a osgeo4w install somewhere with QGIS-dev on it.
The (manual) update today failed because: libprotobuf-lite.dll was not
found.

After searching in the lib part of the osgeo4w installer I found a lib
protobuf and installed that one.
After that QGIS installed fine.

Is this a missing dependency maybe?
Or is it an artifact because of the manual updates?

Regards,

Richard Duivenvoorde
___
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] EditInPlace Processing script

2020-04-09 Thread matteo
Thanks Arnaud, will try and let you know!

Cheers

Matteo
___
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] Server: The legend anchored point will be reset to up left when WMS GetPrint

2020-04-09 Thread René-Luc Dhont

Hi devs,

I have found an issue in QGIS Server and I am not able to fix it.
I have firstly create the test to confirm the bug 
https://github.com/qgis/QGIS/pull/35060


The issue is that the anchored point of a legend layout item is reset 
when the QGIS Server performs a print.
I cannot reproduce the issue with QGIS Desktop. The anchored point is 
never reset whatever the options and configurations of the associated map.

I did not find how the anchored point can be reset for a layout item.

Thanks in advanced for your help.
Regards,
René-Luc
___
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] EditInPlace Processing script

2020-04-09 Thread Arnaud Morvan

Note that when heriting form QgsProcessingFeatureBasedAlgorithm,

you do not have to implement processAlgorithm method which is already 
implemented in QgsProcessingFeatureBasedAlgorithm


but should implement the processFeature method.

Arnaud Morvan
Ingénieur logiciel
Tél: +33 (0)4 58 48 20 32

Camptocamp France SAS
18 rue du Lac Saint André
Savoie Technolac - Bâtiment Le Dauphin
F-73370 Le Bourget du Lac
http://www.camptocamp.com

Le 09/04/2020 à 13:35, Arnaud Morvan a écrit :

Hello Matteo,

As far as I know, if your algorithm :

    does not change the table structure (geometry type, fields list 
and their types)


    is an instance of QgsProcessingFeatureBasedAlgorithm (output one 
feature for each input feature)


In brief:

    - If your algorithm output one feature for each input feature:

       => your should inherit from QgsProcessingFeatureBasedAlgorithm.

    - If your outputs features have same geometry type and same fields 
with same types:


       => you can put the flag on your algorithm as it can be used for 
in place editing.


When in place editing is checked in dialog, output features replace 
input features in source instead of being appended to an output.


Arnaud Morvan
Ingénieur logiciel
Tél: +33 (0)4 58 48 20 32

Camptocamp France SAS
18 rue du Lac Saint André
Savoie Technolac - Bâtiment Le Dauphin
F-73370 Le Bourget du Lac
http://www.camptocamp.com

Le 09/04/2020 à 10:53, matteo a écrit :

Hi all,

is it possible to write a custom Processing script that can edit the
input layer in place (with the core functionality of course)?

In the documentation I found the method to check if the algorithm
supports the in place editing [0] but not the method to set the script
to support the functionality.

There are a few python core algorithms with

Thanks for any hint!

Cheers

Matteo


[0]
https://qgis.org/pyqgis/3.10/core/QgsProcessingAlgorithm.html#qgis.core.QgsProcessingAlgorithm.supportInPlaceEdit 


___
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] EditInPlace Processing script

2020-04-09 Thread Arnaud Morvan

Hello Matteo,

As far as I know, if your algorithm :

    does not change the table structure (geometry type, fields list and 
their types)


    is an instance of QgsProcessingFeatureBasedAlgorithm (output one 
feature for each input feature)


In brief:

    - If your algorithm output one feature for each input feature:

       => your should inherit from QgsProcessingFeatureBasedAlgorithm.

    - If your outputs features have same geometry type and same fields 
with same types:


       => you can put the flag on your algorithm as it can be used for 
in place editing.


When in place editing is checked in dialog, output features replace 
input features in source instead of being appended to an output.


Arnaud Morvan
Ingénieur logiciel
Tél: +33 (0)4 58 48 20 32

Camptocamp France SAS
18 rue du Lac Saint André
Savoie Technolac - Bâtiment Le Dauphin
F-73370 Le Bourget du Lac
http://www.camptocamp.com

Le 09/04/2020 à 10:53, matteo a écrit :

Hi all,

is it possible to write a custom Processing script that can edit the
input layer in place (with the core functionality of course)?

In the documentation I found the method to check if the algorithm
supports the in place editing [0] but not the method to set the script
to support the functionality.

There are a few python core algorithms with

Thanks for any hint!

Cheers

Matteo


[0]
https://qgis.org/pyqgis/3.10/core/QgsProcessingAlgorithm.html#qgis.core.QgsProcessingAlgorithm.supportInPlaceEdit
___
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 [1813] Geometric Attributes approval notification.

2020-04-09 Thread noreply

Plugin Geometric Attributes approval by pcav.
The plugin version "[1813] Geometric Attributes 0.3" is now approved
Link: http://plugins.qgis.org/plugins/geometric_attributes/
___
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] EditInPlace Processing script

2020-04-09 Thread matteo
Hi all,

is it possible to write a custom Processing script that can edit the
input layer in place (with the core functionality of course)?

In the documentation I found the method to check if the algorithm
supports the in place editing [0] but not the method to set the script
to support the functionality.

There are a few python core algorithms with

Thanks for any hint!

Cheers

Matteo


[0]
https://qgis.org/pyqgis/3.10/core/QgsProcessingAlgorithm.html#qgis.core.QgsProcessingAlgorithm.supportInPlaceEdit
___
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 [970] TUFLOW approval notification.

2020-04-09 Thread noreply

Plugin TUFLOW approval by pcav.
The plugin version "[970] TUFLOW 3.0.5" is now approved
Link: http://plugins.qgis.org/plugins/tuflow/
___
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