Re: [QGIS-Developer] Time for db manager to become an "opt-in" plugin?

[Nyall Dawson via QGIS-Developer]

On Wed, 22 Jun 2022 at 15:46, Paolo Cavallini via QGIS-Developer
 wrote:
>
> +1 from me. the current state is really confusing.
> there are a number of functions that are still missing from core, but
> what is really used can be added later, in the meantime the external
> plugin can do the job.

Right -- for completeness, here's my understanding of the
functionality available through db manager which ISN'T yet available
via the browser:

- Saving/re-running previously saved SQL queries
- Switching to the simplified "SQL builder" dialog for creating a SQL query
- Truncating a table (this is available through a Processing
algorithm, just not via browser)
- Attribute index creation (this is available through a Processing
algorithm, just not via browser)
- !! Support for editing an existing column (changing name/type). This
is the biggest functionality gap -- changing existing column types is
not available elsewhere in QGIS
- Listing database triggers

Nyall



> thanks Nyall for raising this.
> cheers.
>
> Il 22/06/22 02:43, Nyall Dawson via QGIS-Developer ha scritto:
> > Hi list,
> >
> > I wanted to raise the discussion around potentially demoting the DB
> > Manager plugin to become an opt-in, not installed by default plugin
> > available from the QGIS plugin repository only.
> >
> > It's likely no surprise to anyone on this list, but there's been a
> > multi-year effort (mostly thanks to Alessandro!) to move all the
> > important functionality of db manager over to the QGIS browser. This was
> > driven by a number of factors:
> >
> > - It was confusing and messy to expose database management tools through
> > two completely separate parts of the QGIS interface
> > - The DB Manager tools are written in provider-specific ways, and don't
> > use generic QGIS database/provider API calls. As a result there's a lot
> > of duplicate code there, and db manager doesn't gain the benefits of new
> > data provider features. (E.g. only a subset of the databases supported
> > by QGIS and the browser management tools are available for management in
> > db manager)
> > - The DB Manager functionality wasn't available for other parts of
> > QGIS/plugins/scripts/etc to reuse, whereas the browser functionality is
> > all nicely exposed to PyQGIS and is used by other parts of QGIS, eg.
> > processing tools.
> > - The Python code implementing db manager is fragile, and is subject to
> > semi-frequent regressions/breakage (through no fault of the authors --
> > it's just the nature of complex python applications which aren't soaked
> > in unit tests)
> >
> > I'd say we've reached a stage where the browser now offers all the
> > common functionality also available in db manager, and we can start to
> > seriously discuss the future of the plugin.
> >
> > My personal view is that we should demote the plugin to a
> > community-maintained, non-officially supported plugin available only
> > through the QGIS plugin repositories, and remove it from the default
> > QGIS install.
> >
> > Thoughts/discussion welcome :)
> >
> > 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
>
> --
> Paolo Cavallini
> www.faunalia.eu - QGIS.org
> 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 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] Time for db manager to become an "opt-in" plugin?

[Paolo Cavallini via QGIS-Developer]

+1 from me. the current state is really confusing.
there are a number of functions that are still missing from core, but
what is really used can be added later, in the meantime the external
plugin can do the job.
thanks Nyall for raising this.
cheers.

Il 22/06/22 02:43, Nyall Dawson via QGIS-Developer ha scritto:
> Hi list,
> 
> I wanted to raise the discussion around potentially demoting the DB
> Manager plugin to become an opt-in, not installed by default plugin
> available from the QGIS plugin repository only.
> 
> It's likely no surprise to anyone on this list, but there's been a
> multi-year effort (mostly thanks to Alessandro!) to move all the
> important functionality of db manager over to the QGIS browser. This was
> driven by a number of factors:
> 
> - It was confusing and messy to expose database management tools through
> two completely separate parts of the QGIS interface
> - The DB Manager tools are written in provider-specific ways, and don't
> use generic QGIS database/provider API calls. As a result there's a lot
> of duplicate code there, and db manager doesn't gain the benefits of new
> data provider features. (E.g. only a subset of the databases supported
> by QGIS and the browser management tools are available for management in
> db manager)
> - The DB Manager functionality wasn't available for other parts of
> QGIS/plugins/scripts/etc to reuse, whereas the browser functionality is
> all nicely exposed to PyQGIS and is used by other parts of QGIS, eg.
> processing tools.
> - The Python code implementing db manager is fragile, and is subject to
> semi-frequent regressions/breakage (through no fault of the authors --
> it's just the nature of complex python applications which aren't soaked
> in unit tests)
> 
> I'd say we've reached a stage where the browser now offers all the
> common functionality also available in db manager, and we can start to
> seriously discuss the future of the plugin.
> 
> My personal view is that we should demote the plugin to a
> community-maintained, non-officially supported plugin available only
> through the QGIS plugin repositories, and remove it from the default
> QGIS install.
> 
> Thoughts/discussion welcome :)
> 
> 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

-- 
Paolo Cavallini
www.faunalia.eu - QGIS.org
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] Time for db manager to become an "opt-in" plugin?

[Nyall Dawson via QGIS-Developer]

Hi list,

I wanted to raise the discussion around potentially demoting the DB Manager
plugin to become an opt-in, not installed by default plugin available from
the QGIS plugin repository only.

It's likely no surprise to anyone on this list, but there's been a
multi-year effort (mostly thanks to Alessandro!) to move all the important
functionality of db manager over to the QGIS browser. This was driven by a
number of factors:

- It was confusing and messy to expose database management tools through
two completely separate parts of the QGIS interface
- The DB Manager tools are written in provider-specific ways, and don't use
generic QGIS database/provider API calls. As a result there's a lot of
duplicate code there, and db manager doesn't gain the benefits of new data
provider features. (E.g. only a subset of the databases supported by QGIS
and the browser management tools are available for management in db manager)
- The DB Manager functionality wasn't available for other parts of
QGIS/plugins/scripts/etc to reuse, whereas the browser functionality is all
nicely exposed to PyQGIS and is used by other parts of QGIS, eg. processing
tools.
- The Python code implementing db manager is fragile, and is subject to
semi-frequent regressions/breakage (through no fault of the authors -- it's
just the nature of complex python applications which aren't soaked in unit
tests)

I'd say we've reached a stage where the browser now offers all the common
functionality also available in db manager, and we can start to seriously
discuss the future of the plugin.

My personal view is that we should demote the plugin to a
community-maintained, non-officially supported plugin available only
through the QGIS plugin repositories, and remove it from the default QGIS
install.

Thoughts/discussion welcome :)

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] Qgis server: terrible performance with Qgis 3.26

[David Marteau via QGIS-Developer]

I Wonder why we have `Creating auxiliary storage` that takes 65.0 ms in 
Qgis 3.26 and it does not appears in Qgis 3.24:
I need to figure how auxiliary layers are loaded in Qgis 3.24 (are they 
loaded lazily ?).


I happends that loading auxiliary layer is negligible in 3.24 :

>> projectload, Creating auxiliary storage: 0.0 ms

I do not understand the difference because it appears that it looks like 
the same code in 3.24 and 3.26.


Does compile/optimize options could have changed between release 3.24 
and 3.26 ?



Le 21/06/2022 à 14:45, David Marteau a écrit :


Hi,

Here is a first analysis using QgsRuntimeProfiler outputs

The project is the same in all tests and has been saved with Qgis 3.26.
This is a first load in each case just after qgis init, so there 
should be no caching involved.


Output has been filtered to `projectload` profiler group and rows with 
elapsed time > 0


All builds are official builds and installed from qgis.org packages.
Tests are run in Docker container with ubuntu 21.04

Total time show a variance of +/- 25% on multiple runs.

## Qgis 3.26

### Flags
* Qgis.ProjectReadFlag.TrustLayerMetadata
* Qgis.ProjectReadFlag.DontLoad3DViews
* Qgis.ProjectReadFlag.DontLoadProjectStyles

projectload, Reading project file: 21.0 ms
projectload, Creating auxiliary storage: 65.0 ms
projectload, Reading properties: 19.0 ms
projectload, Reading map layers: 14.0 ms
-projectload, france_parts: 6.0 ms
--projectload, Load layer source: 5.0 ms
---projectload, Create ogr provider: 3.0 ms
-projectload, france_parts bordure: 4.0 ms
--projectload, Load layer source: 4.0 ms
---projectload, Create ogr provider: 2.0 ms
-projectload, france_parts tuilé en cache: 3.0 ms
--projectload, Load layer source: 3.0 ms
---projectload, Create ogr provider: 1.0 ms
projectload, Storing original layer properties: 2.0 ms

Total time: 152.0 ms

## Qgis 3.24

### Flags
* QgsProject.FlagTrustLayerMetadata

projectload, Reading project file: 5.0 ms
projectload, Reading properties: 4.0 ms
projectload, Reading map layers: 4.0 ms
-projectload, france_parts: 1.0 ms
--projectload, Load layer source: 1.0 ms
-projectload, france_parts bordure: 1.0 ms
--projectload, Load layer source: 1.0 ms
-projectload, france_parts tuilé en cache: 1.0 ms
--projectload, Load layer source: 1.0 ms
projectload, Storing original layer properties: 1.0 ms
projectload, Updating interface: 1.0 ms

Total time: 21.0 ms

Some remarks:

I Wonder why we have `Creating auxiliary storage` that takes 65.0 ms 
in Qgis 3.26 and it does not appears in Qgis 3.24:
I need to figure how auxiliary layers are loaded in Qgis 3.24 (are 
they loaded lazily ?).


The `Reading project file`, `Reading properties` and `Reading map 
layers` sections are almost 3 to 4 times slower in Qgis 3.26.


The loading of layers ares also slower in Qgis 3.26 compared to Qgis 3.24.


Le 21/06/2022 à 12:27, David Marteau a écrit :



May be I could use QgsRuntimeProfiler output in first place ?

Le 20/06/2022 à 18:55, Even Rouault a écrit :


Use sysprof or just run under a debugger and interrupt regularly 
should help you spot in which method(s) most time is spent


Le 20/06/2022 à 18:48, David Marteau via QGIS-Developer a écrit :


I used the following test:

readflags = Qgis.ProjectReadFlags() readflags |= 
Qgis.ProjectReadFlag.TrustLayerMetadata|Qgis.ProjectReadFlag.DontLoad3DViews|Qgis.ProjectReadFlag.DontLoadProjectStyles 
prj = QgsProject()%timeit -n 1 
prj.read(f"{datapath}/france_parts3_26.qgs",readflags)


105 ms ± 18.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

This improve the result  but we are still much higher that the 
loading time of 3.24: 15ms compared to 105ms



Le 20/06/2022 à 18:38, Nyall Dawson a écrit :



On Mon, 20 June 2022, 11:42 pm David Marteau,  
wrote:


Hi,

> You should set the other new read optimisation flags here --
see

https://github.com/qgis/QGIS/blob/88ebb3f2f513dbce5a775f50e51ea0117f859c65/src/core/qgis.h#L1962

These are already available also in 3.24 and we use the  
`TrustLayerMetadata` in the above test. For server,  the other
flags are not applicable (Getprint requests need print layouts ).

So that mean we are comparing 3.24 to 3.26 with same level of
read optimisation and that does not change the fact that, for
that very same level of read optimisation, project's loading
is incredibly slower in 3.26.


You'll need to set the new flags relating to skipping the 3d views 
and project style loading in order to compare properly. Neither of 
those things were occurring in 3.24, and both have an associated 
cost. And neither are relevant for server.


Nyall



Le 20/06/2022 à 15:10, Nyall Dawson a écrit :



On Mon, 20 June 2022, 9:37 pm David Marteau via
QGIS-Developer,  wrote:

Hi,

I have noticed a huge drop of performance while testing
Qgis server with Qgis 3.26, from 10x to 30x slower as usual.

Trying to reduce the problem I have found a huge 

Re: [QGIS-Developer] Qgis server: terrible performance with Qgis 3.26

[David Marteau via QGIS-Developer]

Hi,

Here is a first analysis using QgsRuntimeProfiler outputs

The project is the same in all tests and has been saved with Qgis 3.26.
This is a first load in each case just after qgis init, so there should 
be no caching involved.


Output has been filtered to `projectload` profiler group and rows with 
elapsed time > 0


All builds are official builds and installed from qgis.org packages.
Tests are run in Docker container with ubuntu 21.04

Total time show a variance of +/- 25% on multiple runs.

## Qgis 3.26

### Flags
* Qgis.ProjectReadFlag.TrustLayerMetadata
* Qgis.ProjectReadFlag.DontLoad3DViews
* Qgis.ProjectReadFlag.DontLoadProjectStyles

projectload, Reading project file: 21.0 ms
projectload, Creating auxiliary storage: 65.0 ms
projectload, Reading properties: 19.0 ms
projectload, Reading map layers: 14.0 ms
-projectload, france_parts: 6.0 ms
--projectload, Load layer source: 5.0 ms
---projectload, Create ogr provider: 3.0 ms
-projectload, france_parts bordure: 4.0 ms
--projectload, Load layer source: 4.0 ms
---projectload, Create ogr provider: 2.0 ms
-projectload, france_parts tuilé en cache: 3.0 ms
--projectload, Load layer source: 3.0 ms
---projectload, Create ogr provider: 1.0 ms
projectload, Storing original layer properties: 2.0 ms

Total time: 152.0 ms

## Qgis 3.24

### Flags
* QgsProject.FlagTrustLayerMetadata

projectload, Reading project file: 5.0 ms
projectload, Reading properties: 4.0 ms
projectload, Reading map layers: 4.0 ms
-projectload, france_parts: 1.0 ms
--projectload, Load layer source: 1.0 ms
-projectload, france_parts bordure: 1.0 ms
--projectload, Load layer source: 1.0 ms
-projectload, france_parts tuilé en cache: 1.0 ms
--projectload, Load layer source: 1.0 ms
projectload, Storing original layer properties: 1.0 ms
projectload, Updating interface: 1.0 ms

Total time: 21.0 ms

Some remarks:

I Wonder why we have `Creating auxiliary storage` that takes 65.0 ms in 
Qgis 3.26 and it does not appears in Qgis 3.24:
I need to figure how auxiliary layers are loaded in Qgis 3.24 (are they 
loaded lazily ?).


The `Reading project file`, `Reading properties` and `Reading map 
layers` sections are almost 3 to 4 times slower in Qgis 3.26.


The loading of layers ares also slower in Qgis 3.26 compared to Qgis 3.24.


Le 21/06/2022 à 12:27, David Marteau a écrit :



May be I could use QgsRuntimeProfiler output in first place ?

Le 20/06/2022 à 18:55, Even Rouault a écrit :


Use sysprof or just run under a debugger and interrupt regularly 
should help you spot in which method(s) most time is spent


Le 20/06/2022 à 18:48, David Marteau via QGIS-Developer a écrit :


I used the following test:

readflags = Qgis.ProjectReadFlags() readflags |= 
Qgis.ProjectReadFlag.TrustLayerMetadata|Qgis.ProjectReadFlag.DontLoad3DViews|Qgis.ProjectReadFlag.DontLoadProjectStyles 
prj = QgsProject()%timeit -n 1 
prj.read(f"{datapath}/france_parts3_26.qgs",readflags)


105 ms ± 18.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

This improve the result  but we are still much higher that the 
loading time of 3.24: 15ms compared to 105ms



Le 20/06/2022 à 18:38, Nyall Dawson a écrit :



On Mon, 20 June 2022, 11:42 pm David Marteau,  
wrote:


Hi,

> You should set the other new read optimisation flags here --
see

https://github.com/qgis/QGIS/blob/88ebb3f2f513dbce5a775f50e51ea0117f859c65/src/core/qgis.h#L1962

These are already available also in 3.24 and we use the  
`TrustLayerMetadata` in the above test. For server,  the other
flags are not applicable (Getprint requests need print layouts ).

So that mean we are comparing 3.24 to 3.26 with same level of
read optimisation and that does not change the fact that, for
that very same level of read optimisation, project's loading is
incredibly  slower in 3.26.


You'll need to set the new flags relating to skipping the 3d views 
and project style loading in order to compare properly. Neither of 
those things were occurring in 3.24, and both have an associated 
cost. And neither are relevant for server.


Nyall



Le 20/06/2022 à 15:10, Nyall Dawson a écrit :



On Mon, 20 June 2022, 9:37 pm David Marteau via
QGIS-Developer,  wrote:

Hi,

I have noticed a huge drop of performance while testing
Qgis server with Qgis 3.26, from 10x to 30x slower as usual.

Trying to reduce the problem I have found a huge increase
of time spend reading the project in 3.26 compared to 3.24.

Here some benchmark with very simple project from the test
data set. Note: the project has been updated with qgis 3.26:

Qgis 3.24:
==

readflags = QgsProject.ReadFlags()readflags |=
QgsProject.FlagTrustLayerMetadata

prj = QgsProject()

%timeit -n 1
prj.read(f"{datapath}/france_parts.qgs",readflags)

> 15.7 ms ± 205 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)

Qgis 3.26:
==

  

Re: [QGIS-Developer] Qgis server: terrible performance with Qgis 3.26

[David Marteau via QGIS-Developer]

May be I could use QgsRuntimeProfiler output in first place ?

Le 20/06/2022 à 18:55, Even Rouault a écrit :


Use sysprof or just run under a debugger and interrupt regularly 
should help you spot in which method(s) most time is spent


Le 20/06/2022 à 18:48, David Marteau via QGIS-Developer a écrit :


I used the following test:

readflags = Qgis.ProjectReadFlags() readflags |= 
Qgis.ProjectReadFlag.TrustLayerMetadata|Qgis.ProjectReadFlag.DontLoad3DViews|Qgis.ProjectReadFlag.DontLoadProjectStyles 
prj = QgsProject()%timeit -n 1 
prj.read(f"{datapath}/france_parts3_26.qgs",readflags)


105 ms ± 18.5 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

This improve the result  but we are still much higher that the 
loading time of 3.24: 15ms compared to 105ms



Le 20/06/2022 à 18:38, Nyall Dawson a écrit :



On Mon, 20 June 2022, 11:42 pm David Marteau,  wrote:

Hi,

> You should set the other new read optimisation flags here --
see

https://github.com/qgis/QGIS/blob/88ebb3f2f513dbce5a775f50e51ea0117f859c65/src/core/qgis.h#L1962

These are already available also in 3.24 and we use the  
`TrustLayerMetadata` in the above test. For server,  the other
flags are not applicable (Getprint requests need print layouts ).

So that mean we are comparing 3.24 to 3.26 with same level of
read optimisation and that does not change the fact that, for
that very same level of read optimisation, project's loading is
incredibly  slower in 3.26.


You'll need to set the new flags relating to skipping the 3d views 
and project style loading in order to compare properly. Neither of 
those things were occurring in 3.24, and both have an associated 
cost. And neither are relevant for server.


Nyall



Le 20/06/2022 à 15:10, Nyall Dawson a écrit :



On Mon, 20 June 2022, 9:37 pm David Marteau via QGIS-Developer,
 wrote:

Hi,

I have noticed a huge drop of performance while testing
Qgis server with Qgis 3.26, from 10x to 30x slower as usual.

Trying to reduce the problem I have found a huge increase
of time spend reading the project in 3.26 compared to 3.24.

Here some benchmark with very simple project from the test
data set. Note: the project has been updated with qgis 3.26:

Qgis 3.24:
==

readflags = QgsProject.ReadFlags()readflags |=
QgsProject.FlagTrustLayerMetadata

prj = QgsProject()

%timeit -n 1 prj.read(f"{datapath}/france_parts.qgs",readflags)

> 15.7 ms ± 205 µs per loop (mean ± std. dev. of 7 runs, 1 loop each)

Qgis 3.26:
==

readflags = QgsProject.ReadFlags() readflags |=
QgsProject.FlagTrustLayerMetadata


You should set the other new read optimisation flags here --
see

https://github.com/qgis/QGIS/blob/88ebb3f2f513dbce5a775f50e51ea0117f859c65/src/core/qgis.h#L1962

Nyall

​prj = QgsProject()

%timeit -n 1 prj.read(f"{datapath}/france_parts.qgs",readflags)

195 ms ± 44 ms per loop (mean ± std. dev. of 7 runs, 1 loop each)

There is a factor x10 between Qgis 3.24 et Qgis 3.26 for
the exact same project.
This has serious impact on requests: landing page catalog
request time increased from approximatevely 110ms to more
than 3.0s with our test data set.


David Marteau
www.3liz.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

--
http://www.spatialys.com
My software is free, but my time generally not.___
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-community-team] Changelog, please check

[Richard Duivenvoorde via QGIS-Developer]

Thanks, but the dump of changelog.qgis.org is already pulled into the website 
(and manually edited etc)..

Only way to get it into qgis.org site is to add a block manually in the rst and 
add the image and link to

https://github.com/qgis/QGIS-Website/edit/master/source/site/forusers/visualchangelog326/index.rst

I Just did:
https://github.com/qgis/QGIS-Website/commit/c9d2105d3ea1f838a1b4df8dbe520af7881ae37f

So should pop up in qgis.org next build (tonight)

Dev's please keep an eye on changelog.qgis.org during release time, Thanks.

Regards,

Richard


On 6/21/22 09:27, Totò Fiandaca wrote:

I added the PR to this link

https://changelog.qgis.org/en/qgis/version/3.26/#scalebar-data-defined-overrides 


Il giorno lun 20 giu 2022 alle ore 15:42 Ethan Snyder via QGIS-Developer 
mailto:qgis-developer@lists.osgeo.org>> ha 
scritto:

Richard:

__ __

     This new feature is missing from the changelog (probably because it 
didn’t get all the proper tags): https://github.com/qgis/QGIS/pull/48929 


     It was primarily authored by me (Ethan Snyder), and polished 
and merged by Nyall.

__ __

     Here’s the original PR which Nyall copied for changes: 
https://github.com/qgis/QGIS/pull/48314 


__ __

Thanks,

__ __

Ethan Snyder

__ __

*From:* Tim Sutton mailto:t...@kartoza.com>>
*Sent:* Saturday, June 18, 2022 7:33 AM
*To:* Richard Duivenvoorde mailto:rdmaili...@duif.net>>
*Cc:* qgis-developer mailto:qgis-developer@lists.osgeo.org>>; qgis-community 
mailto:qgis-community-t...@lists.osgeo.org>>
*Subject:* Re: [QGIS-Developer] [Qgis-community-team] Changelog, please 
check

__ __

That looks great @Richard Duivenvoorde   thanks 
so much!

__ __

Regards

__ __

Tim

__ __

On Sat, Jun 18, 2022 at 5:54 AM Richard Duivenvoorde mailto:rdmaili...@duif.net>> wrote:

Hi People,

I (silently) added the visual changelog 3.26 to the site already, 
please check:

https://qgis.org/en/site/forusers/visualchangelog326/index.html 


for any glitches.

If found, either let me know, or just fix it yourself in the rst at


https://github.com/qgis/QGIS-Website/edit/master/source/site/forusers/visualchangelog326/index.rst
 


so I can push stuff to transifex (for translations) after the packaging 
is finished (when the banner has also been updated).

Regards,

Richard Duivenvoorde
___
Qgis-community-team mailing list for organizing community resources 
such as documentation, translation etc..
qgis-community-t...@lists.osgeo.org 

https://lists.osgeo.org/mailman/listinfo/qgis-community-team 





__ __

-- 


--

​

Image removed by sender.

Tim Sutton

Visit http://kartoza.com  to find out about open 
source:
  * Desktop GIS programming services
  * Geospatial web development

* GIS Training

* Consulting Services

Tim is a member of the QGIS Project Steering Committee


---

DISCLAIMER: This message and any documents attached may contain confidential 
information and are intended only for the individual(s) named. If you are not the 
intended recipient, or the employee or agent authorized to received for the 
intended recipient, you should not disseminate, distribute or copy this e-mail and 
any attached documents. If you have received this e-mail in error, please 
immediately notify the sender at Remington & Vernick Engineers by replying to 
this e-mail and delete the original e-mail and any reply e-mail messages from your 
system. E-mail transmission cannot be guaranteed to be secure or error-free as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender therefore does not accept liability for 
any errors or omissions in the contents of this message, which arise as a result of 
e-mail transmission. If verification is required please request a hard-copy 
version. Thank you.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org 

Re: [QGIS-Developer] [Qgis-community-team] Changelog, please check

[Totò Fiandaca via QGIS-Developer]

I added the PR to this link

https://changelog.qgis.org/en/qgis/version/3.26/#scalebar-data-defined-overrides

Il giorno lun 20 giu 2022 alle ore 15:42 Ethan Snyder via QGIS-Developer <
qgis-developer@lists.osgeo.org> ha scritto:

> Richard:
>
>
>
> This new feature is missing from the changelog (probably
> because it didn’t get all the proper tags):
> https://github.com/qgis/QGIS/pull/48929
>
> It was primarily authored by me (Ethan Snyder), and polished
> and merged by Nyall.
>
>
>
> Here’s the original PR which Nyall copied for changes:
> https://github.com/qgis/QGIS/pull/48314
>
>
>
> Thanks,
>
>
>
> Ethan Snyder
>
>
>
> *From:* Tim Sutton 
> *Sent:* Saturday, June 18, 2022 7:33 AM
> *To:* Richard Duivenvoorde 
> *Cc:* qgis-developer ; qgis-community <
> qgis-community-t...@lists.osgeo.org>
> *Subject:* Re: [QGIS-Developer] [Qgis-community-team] Changelog, please
> check
>
>
>
> That looks great @Richard Duivenvoorde   thanks so
> much!
>
>
>
> Regards
>
>
>
> Tim
>
>
>
> On Sat, Jun 18, 2022 at 5:54 AM Richard Duivenvoorde 
> wrote:
>
> Hi People,
>
> I (silently) added the visual changelog 3.26 to the site already, please
> check:
>
> https://qgis.org/en/site/forusers/visualchangelog326/index.html
>
> for any glitches.
>
> If found, either let me know, or just fix it yourself in the rst at
>
>
> https://github.com/qgis/QGIS-Website/edit/master/source/site/forusers/visualchangelog326/index.rst
>
> so I can push stuff to transifex (for translations) after the packaging is
> finished (when the banner has also been updated).
>
> Regards,
>
> Richard Duivenvoorde
> ___
> Qgis-community-team mailing list for organizing community resources such
> as documentation, translation etc..
> qgis-community-t...@lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/qgis-community-team
>
>
>
>
> --
>
>
> --
>
> ​
>
> [image: Image removed by sender.]
>
> Tim Sutton
>
> Visit http://kartoza.com to find out about open source:
>  * Desktop GIS programming services
>  * Geospatial web development
>
> * GIS Training
>
> * Consulting Services
>
> Tim is a member of the QGIS Project Steering Committee
>
>
> ---
> DISCLAIMER: This message and any documents attached may contain
> confidential information and are intended only for the individual(s) named.
> If you are not the intended recipient, or the employee or agent authorized
> to received for the intended recipient, you should not disseminate,
> distribute or copy this e-mail and any attached documents. If you have
> received this e-mail in error, please immediately notify the sender at
> Remington & Vernick Engineers by replying to this e-mail and delete the
> original e-mail and any reply e-mail messages from your system. E-mail
> transmission cannot be guaranteed to be secure or error-free as information
> could be intercepted, corrupted, lost, destroyed, arrive late or
> incomplete, or contain viruses. The sender therefore does not accept
> liability for any errors or omissions in the contents of this message,
> which arise as a result of e-mail transmission. If verification is required
> please request a hard-copy version. Thank you.
> ___
> 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
>


-- 
*Ing. Salvatore Fiandaca*
*mobile*.:+39 327.493.8955
*m*: *pigrecoinfin...@gmail.com *
*C.F*.: FNDSVT71E29Z103G
*P.IVA*: 06597870820
*membro QGIS Italia - http://qgis.it/ *
*socio GFOSS.it - *http://gfoss.it/
*blog:*
* https://pigrecoinfinito.com/  FB: Co-admin
- https://www.facebook.com/qgis.it/ **
 *
*TW:  **https://twitter.com/totofiandaca
*

43°51'0.54"N  10°34'27.62"E - EPSG:4326

“Se la conoscenza deve essere aperta a tutti,
perchè mai limitarne l’accesso?”
R. Stallman

Questo documento, allegati inclusi, contiene informazioni di proprietà di
FIANDACA SALVATORE e deve essere utilizzato esclusivamente dal destinatario
in relazione alle finalità per le quali è stato ricevuto. E' vietata
qualsiasi forma di riproduzione o divulgazione senza l'esplicito consenso
di FIANDACA SALVATORE. Qualora fosse stato ricevuto per errore si prega di
informare tempestivamente il mittente e distruggere la copia in proprio
possesso.
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: