Re: [QGIS-Developer] What’s the purpose of fatalError argument in QgsProcessingFeedback.reportError() ?

[Nyall Dawson via QGIS-Developer]

On Mon, 23 Sept 2024 at 22:34, Nicolas Godet via QGIS-Developer
 wrote:
>
> Hi Julien,
>
> I was referring to 
> https://github.com/qgis/QGIS/blob/0b11a7c36c446c37534c3c4c8f25c803640b780a/src/core/processing/qgsprocessingfeedback.cpp#L62-L69.
>
> Looking at the calls to this method in the algorithms, I came to the same 
> explanation as you.
> But maybe I was missing something...

It's basically just there for legacy reasons (it was part of the
original port of processing to c++ in 3.0), and doesn't serve a real
purpose in current supported versions. We should remove it for 4.0.

Nyall


>
> Thanks !
> Nicolas
>
> 
> De : Julien Cabieces 
> Envoyé : lundi 23 septembre 2024 10:39
> À : Nicolas Godet via QGIS-Developer 
> Cc : Nicolas Godet 
> Objet : Re: [QGIS-Developer] What’s the purpose of fatalError argument in 
> QgsProcessingFeedback.reportError() ?
>
>
> Hi Nicolas,
>
>
> > Dear devs,
> >
> > Title says it all. Looking at the code, this argument is never used.
> >
>
> It is actually 
> https://github.com/qgis/QGIS/blob/a2626a2a427afc5d139061e43ade0e62bafda8ad/src/analysis/processing/qgsalgorithmdissolve.cpp#L303
>
> > I first understood it would stop the algorithm but no.
>
> It doesn't stop the algorithm, the algorithm has to
> stop by itself after it detects and report the fatal error. This boolean is 
> usefull
> for other classes that would implement feedback to be aware that the
> algorithm has to stop, and so act as such, like printing a red colored
> message FATAL ERROR for instance.
>
> This is how I understand the rationale of this boolean.
>
> > Sorry for my ignorance…
> >
>
> Don't be :)
>
> Regards,
> Julien
>
> > Regards,
> > Nicolas
> > ___
> > 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
>
> --
>
> Julien Cabieces
> Senior Developer at Oslandia
> julien.cabie...@oslandia.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

Re: [QGIS-Developer] QGIS Unexpectedly Crashing

[Nyall Dawson via QGIS-Developer]

On Sun, 25 Aug 2024 at 12:51, Catania, Luke A ERDC-RDE-GRL-VA CIV via
QGIS-Developer  wrote:
>
> What causes an access violation intermittently?  Once it happens sometimes it 
> continues to happen, and I have to delete the QGIS directory in 
> AppData\Roaming\ which is annoying because I have my plugin there and I need 
> to copy it to another directory and then copy it back after running QGIS for 
> first time to have the directory recreated.
>
>
>
> It seems to be happening with pyqtgraph\Qt.py which is not my code.

My guess: You've installed pyqtgraph via pip or some binary wheel, and
it's using a different Qt library vs what QGIS is bundled with.

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] Did polygon winding order changed in QGIS or GDAL recently?

[Nyall Dawson via QGIS-Developer]

On Fri, 16 Aug 2024, 10:15 pm Denis Rouzaud via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Some related tickets/PR:
> https://github.com/qgis/QGIS/issues/58333
> https://github.com/qgis/QGIS/pull/55306
>


Those tickets only relate to digitising, they won't affect vector tile
rendering.

Nyall


>
> Le ven. 16 août 2024 à 12:09, Richard Duivenvoorde via QGIS-Developer <
> qgis-developer@lists.osgeo.org> a écrit :
>
>> Recently there was a question on the user list, about the winding order
>> of polygons in json export, which seemed/(was thought to have) changed in
>> time:
>>
>> https://lists.osgeo.org/pipermail/qgis-user/2024-August/054721.html
>>
>> And now the open data vector tiles of the Netherlands, do not work
>> anymore in QGIS (in dutch):
>> https://geoforum.nl/t/bgt-vectortiles-in-qgis-zijn-niet-meer-compleet/9731
>>
>> Their conclusion is: in the standards the OGC winding order is different
>> from the MVT winding order, that is why QGIS (thinking QGIS choose for
>> OGC), is not rendering the MVT tiles anymore...
>>
>> So my question is:
>>
>> - anybody aware of changes of the winding order?
>> - or do we do things 'better' now, breaking older functionality?
>> - or are the pdok mvt tiles wrongly ordered?
>>
>> In the case of MVT tiles (haven't looked into the specs though), but it
>> seems that the reader of the data would respect ordering differences
>> between standards?
>>
>> If you want to checkout the pdok/dutch open data:
>>
>> https://api.pdok.nl/lv/bgt/ogc/v1/tiles/WebMercatorQuad/{z}/{y}/{x}?f=mvt
>> CRS: EPSG:3857
>> Max Zoom Level: 17
>> Styling:
>>
>> https://api.pdok.nl/lv/bgt/ogc/v1/styles/bgt_achtergrondvisualisatie__webmercatorquad?f=mapbox
>>
>> In favour of QGIS, an older Esri osm dataset, is still visible/working:
>>
>>
>> https://basemaps.arcgis.com/arcgis/rest/services/OpenStreetMap_v2/VectorTileServer
>> Max Zoom Level: 19
>>
>> https://www.arcgis.com/sharing/rest/content/items/3e1a00aeae81496587988075fe529f71/resources/styles/root.json?f=pjson
>>
>> Thanks for any pointers!
>>
>> 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
>>
> ___
> 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] Polygons disappearing bug

[Nyall Dawson via QGIS-Developer]

On Thu, 8 Aug 2024 at 03:01, Tasha Anstey via QGIS-Developer
 wrote:
>
> Hi,
>
> Myself and my business partner are daily users of QGIS, and we have notices 
> recently that we have been having problems with polygons disappearing when 
> splitting polygons or editing vertices. Sometimes a seemingly random number 
> and distribution of polygons disappear from the layer being edited. The 
> polygons still exist in the attribute layer but they have a NULL geometry and 
> area. We haven't been able to recover them.

This kind of behaviour is generally a symptom of a corrupted spatial
index in a dataset. Depending on the format the fix will differ, but
you should try either re-creating just the spatial index or (better)
saving the problematic datasets to a new file so that the entire
dataset is re-written from scratch.

I'd also strongly suggest starting a new QGIS user profile and testing
without ANY plugins installed. Plugins are another common cause of
issues like this.

Nyall


>
> Kind regards,
>
> Tasha
>
> Tasha Anstey
> Ground Truth Forestry
> ta...@groundtruthforestry.com | 07553 790460
>
> ___
> 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] QGIS project maintainability, forms and styles, xml verbosity

[Nyall Dawson via QGIS-Developer]

On Tue, 30 Jul 2024 at 20:58, Régis Haubourg via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
> In short, with the growing qgis features, but also datasets becoming
larger (more columns) too, QGIS projects are becoming heavier and heavier,
and require a lot of effort to maintain when trying to ship them as part of
applications or with datasets.

Thanks for raising this discussion -- I agree that it's an important issue,
and one we should address.

> ## First issue, forms are considered as being a part of each style.
>
> This make the qgs xml replicate 6 times the same form, in my case. It
makes it very hard to maintain a single source of truth for this form also.
The idea of having on form per style could be elegant, but it is a path
full of caveats and I suspect very few of us are using this as a feature.

+1. I think that per-style form configuration would be very rarely used,
and should definitely be opt-in rather than something which happens by
default. It's an absolute PAIN to synchronize form configuration across
styles!

A solution could be to move the existing "Show form on ..." combo box from
the form tab into a new "form settings" group, and then add a new checkbox
in there for "Allow different form configuration for different styles"
(which would be off by default for all newly added layers).

I'm sure a lot of users would appreciate this!

>
> ## Second issue, verbosity of the xml
>
> The properties of those forms have grown in time, with many new features
(default values, data defined fonts etc.. ). This is cool.
>
> However in average day use, most of those settings are left as default
values, still QGIS will write every property for each column in the xml.
Ex: default value, hidden status, LabelonTop, etc.  This is highly
denormalized and verbose, mostly for unset properties.  It is so much
denormalized that a simple QGIS xml can weight 18MB and be zipped down to
977 KB.

Agreed.


> Regarding the xml verbosity, suppose we probably could find solutions:
>
>
>  - don't write properties that are left untouched or default (which may
lead to strange behavior when defaults change)

I'd lean toward -0 for this, just because we do occasionally change the
default and the impact of a setting changing in a user's existing project
can be extreme. Rather I'd go with a "don't write properties for properties
which are unset" approach. Eg if a layer doesn't have a vertical CRS set
for, we don't write ANYTHING to the XML (as opposed to verticalCrs="" or
similar). It's a trivial change in code (i.e. checking for an empty string
before writing the attribute) but one which has to be explicitly made, so
we'd need to educate all our developers/reviewers that this is the desired
approach.

>  - don't repeat unuseful informations. ie, layer tree block repeats
provider and datasource even if it is not used. Confusion appears from time
to time when user try to save or modify the xml file because of this
>  - find a less verbose xml serialization if QT allows this. For instance,
instead of on xml block per property, why not have on block per field. For
instance :

*snip*

This one is rather tricky, as it's completely independent pieces of code
which are creating these elements. We'd have to be very careful not to
muddy the QGIS API by tightly linking objects which should remain
independent. I think if we're looking at fixing this properly then a better
approach would be to remove our hard dependency on XML and the Qt DOM
classes, and swap out to some custom class which allows us to freely change
the background format entirely (JSON!). We could even do this without
breaking the API, by "cheating" and making a QgsObjectStorage (?) class
which exposes the same public API as QDomDocument/QDomElement and then
using this throughout our API. (There'd be no break for PyQGIS, because
these objects expose the same API! 😂). And then we'd be free to make this
custom class write/read to/from XML, JSON, YML,  whatever we want.

Even with no other changes in QGIS code a switch to a JSON format would
save a LOT of wasted characters, because we won't have any of those
"duplicate" end tags anymore. We could also avoid all these type="QString",
type="Map" strings because the type would be discernable without having to
explicitly write it out.

Nyall

>
> ```xml
>
> 
> [here dozen of fields]
> 
> 
> 
> [here dozen of fields, again]
> 
> 
> ```
>
> could be
>
> ```xml
> ```
> 
>   ...
>
> 
>
>
> 
> ```
>
>
> To be fair, I have no funding at the moment, but I can try to make it
happen, if we reach a technical consensus here. Any cofunding or grant
proposal would obviously help here. I'm pretty sure companies editing
desktop apps using QGIS could find an interest here.  This thread will
probably raise the question of a new generation project file, but that is
not my intent ;)
>
> Let me know what you think
>
> Cheers
>
> Régis

[QGIS-Developer] QEP 299: Advanced labeling rules

[Nyall Dawson via QGIS-Developer]

Hi list!

Please see https://github.com/qgis/QGIS-Enhancement-Proposals/issues/299
for a newly filed QGIS enhancement proposal regarding advanced labeling
rules.

Advanced rules are project-level settings, which define specific
constraints which must be satisfied during rendering of maps for that
project.

Examples of advanced rules include:

- "Labels from the XX layer must be at least YY millimetres distant from
the features from the ZZ layer"
- "Labels from the XX layer must be at most YY millimetres distant from the
features from the ZZ layer"
- "Labels from the XX layer must be at least YY millimetres distant from
the labels from the ZZ layer"

Users can configure any combination of rules as desired, including multiple
copies of the same rule with different properties (eg different target
layers or different distances)

This will allow a very flexible means for users to fine-tune the exact
label logic for their maps, and provide a framework for more custom
advanced labeling rules to be implemented in future.

Please keep discussion on the linked GitHub ticket.

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] WKT from QgsGeometry incompatible with OGR

[Nyall Dawson via QGIS-Developer]

On Sat, 6 July 2024, 4:56 pm Even Rouault, 
wrote:

> Hi,
>
>
> Both formats are compliant with the WKT specifications.
>
> Are they? I may have missed something in the Simple Features spec, but
> looking at https://portal.ogc.org/files/?artifact_id=25355 , I can't see
> where it would allow the form {geometryTypeName}Z without a space between
> {geometryTypeName} and Z.
>
> For example the BNF at page 56 shows:
>
>  ::= point z 
>
> The examples at page 62 also show a space
>


H What about the examples in 6.1.2.6.4?

Nyall

> .
>
> Even
>
>
> Nyall
>
>
>> A minimal example is below. Executing it will return an exception:
>> "RuntimeError: OGR Error: Corrupt data"
>>
>> from osgeo import ogr
>>
>> qgis_geometyry = QgsGeometry().fromWkt("POINT Z (0 0 0)")
>> wkt = qgis_geometyry.asWkt() # 'PointZ (0 0 0)'
>> ogr.CreateGeometryFromWkt(wkt)
>>
>> ___
>> 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 listqgis-develo...@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] WKT from QgsGeometry incompatible with OGR

[Nyall Dawson via QGIS-Developer]

On Thu, 4 July 2024, 11:19 pm Ivan Barsukov via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hi everyone!
>
> Could you please tell me why the QgsGeometry::asWkt method returns the
> names of geometry types with the Z coordinate without a space (PointZ
> instead of Point Z, etc.)? This value is not compatible with ogr.
>


Both formats are compliant with the WKT specifications. This should rather
be filed as a feature request for GDAL to support the forms without a space.

Nyall


> A minimal example is below. Executing it will return an exception:
> "RuntimeError: OGR Error: Corrupt data"
>
> from osgeo import ogr
>
> qgis_geometyry = QgsGeometry().fromWkt("POINT Z (0 0 0)")
> wkt = qgis_geometyry.asWkt() # 'PointZ (0 0 0)'
> ogr.CreateGeometryFromWkt(wkt)
>
> ___
> 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] [Qgis-psc] Request for review before new release is cut

[Nyall Dawson via QGIS-Developer]

On Sat, 22 Jun 2024 at 06:13, Sandro Santilli via QGIS-PSC
 wrote:
>
>
>
> On June 21, 2024 11:14:59 AM GMT+02:00, "Jürgen E. Fischer via QGIS-PSC" 
>  wrote:
> >On Fri, 21. Jun 2024 at 10:22:14 +0200, Sandro Santilli wrote:
> >> It's packaging time today but I still have 5 pull requests pending 
> >> approval reviews:
> >>
> >>   https://github.com/qgis/QGIS/pulls/strk
> >
> >As far as I can tell none of those are fixes for user facing bugs.
>
>
> 4/5 actually are. One has been now merged by now, btw, so 3/4 are now.

Am I looking at a different PR queue? There's 4 open, 2 of which are
marked as draft and not ready for review (marked as draft by YOU), and
one of which is clearly just an improvement for running tests locally.

So there's 1 PR for a user-facing bug, which until 8 hours ago was
still being reviewed and had comments requiring action.

Can you PLEASE stop sharing misinformation here and inflaming a
situation which doesn't warrant it?

Nyall



>
> --
> Sent from hand-held device with K-9 Mail. Please excuse my brevity.
> ___
> 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] FW: 3D Polygons in PYQGIS

[Nyall Dawson via QGIS-Developer]

On Tue, 4 Jun 2024 at 23:43, Jean Garcia via QGIS-Developer
 wrote:
>
> Good Morning!
>
> I had submitted a question about the usage of 3D functions through PYQGIS 
> (Conversation forwarded below*).
> I attempted the usage of the recommended drape function through PYQGIS and 
> have not had much success.
> (Mainly, how would I create the raster layer from a constant slope?)
> I assume many of my issues has come from me not knowing much about PYQGIS as 
> I am relatively new to the environment.
> This being the case how would I create a 3D layer in which the z values are 
> determined by a constant slope?
> (How would I even determine the start/end of said slope?)

It's still not clear what you're trying to achieve. This is probably
more appropriate for a gis.stackexchange post, along with sketches
illustrating what you're after.

Nyall


>
> Any feedback on my current progress is greatly appreciated!
>
> Many Thanks,
> Jean Garcia
>
> -Original Message-
> From: QGIS-Developer  On Behalf Of 
> Jean Garcia via QGIS-Developer
> Sent: Wednesday, May 29, 2024 9:49 AM
> To: Nyall Dawson 
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [QGIS-Developer] 3D Polygons in PYQGIS
>
> Sorry for the confusion my request might have created.
> I am quite new to QGIS and have had to do a lot of online research with not 
> much success. (mostly vaguely searching through QGIS Documentation)
>
> The project I am working on is to generate a layer based on given parameters, 
> one of said parameters being the slope of each layer's Z Values.
> (one said layer being stated as a slope of 20 to 1 for a horizontal 
> distance of 4,000 ft) With said slope I wish to make the 2D layers I have 
> already generated appear in a 3D view.
>
> I did some research into the drape tool, and while I do believe it could work 
> my issue is how would I create the raster layer with the Z values?
> Since the Z values would depend entirely on the different parameters, it 
> would not be set Z values.
> (What even is the function to create the raster layer?)
>
> My current thinking is to calculate the Z values based on the slope and 
> starting height of each layer.
> How do you think I should go around doing so?
>
> Thanks,
> Jean A. Garcia
>
> -Original Message-
> From: Nyall Dawson 
> Sent: Sunday, May 26, 2024 6:22 PM
> To: Jean Garcia 
> Cc: qgis-developer@lists.osgeo.org
> Subject: Re: [QGIS-Developer] 3D Polygons in PYQGIS
>
> On Fri, 24 May 2024 at 06:09, Jean Garcia via QGIS-Developer 
>  wrote:
> >
> > Good Afternoon,
> >
> >
> >
> > I am currently working on a project that generates a 3D image of a layer. 
> > Is it still not possible to generate a 3D polygon through PYQGIS?
>
> What exactly are you trying to do? There's many ways this request could be 
> interpreted.
>
> (Maybe the "drape" tool from the processing toolbox does what you need?)
>
> Nyall
>
> >
> > I have all the slope values, etc. I have also already made the polygon 
> > layers which I want to convert to 3D.
> >
> > Been looking around and haven't found any solutions that have been able to 
> > help me so this is my last resort before I give up.
> >
> > FYI. I am on version 3.28. This being the case if it is allowed in newer 
> > versions I would still wish to know.
> >
> >
> >
> > Many 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 mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] [Qgis-user] Looking for assistance with fixing RTL label bugs

[Nyall Dawson via QGIS-Developer]

On Mon, 3 June 2024, 6:20 pm Andrea Giudiceandrea via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hi all,
> various user are reporting that the issue no longer occurs on Windows
> using  QGIS 3.34.6 and QGIS 3.36.3 from OSGeo4W.
>
> Since the OSGeo4W installers of both such versions (3.34.6 and 3.36.3)
> ship a bunch of updated libraries [1] (with the Qt library among them),
> then it looks like the root cause of the issue may have been due to a
> library used by QGIS and not to QGIS itself.
>

It's definitely still an issue for curved labels.

Nyall


> Best regards.
>
> Andrea
>
> [1]
> https://lists.osgeo.org/pipermail/qgis-developer/2024-April/066691.html
>
> Il 29/05/2024 12:30, Micha Silver via QGIS-Developer ha scritto:
> > Again thanks for your efforts. I'm sure we'll land on the source of the
> > prob, and find a solution. As I said, I don't think this is a QGIS
> > issue. The underlying bidi library should handle this, AFAIK.
> ___
> 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] [Qgis-user] Looking for assistance with fixing RTL label bugs

[Nyall Dawson via QGIS-Developer]

Thanks for your insights Micha!

Unfortunately I can't solve this one given my lack of language
knowledge. I'll step aside and let a native RTL language developer
take over. I've introduced some tests in
https://github.com/qgis/QGIS/pull/57586 which could be a starting
point for someone.

Nyall

On Tue, 28 May 2024 at 19:13, Micha Silver  wrote:
>
>
> On 28/05/2024 11:34, Nyall Dawson wrote:
>
> Hi Micha,
>
>
> On Tue, 28 May 2024, 6:28 pm Micha Silver,  wrote
>>
>> Thanks for following up on this.
>>
>> The few details (that are mentioned in the issue tracker) that might help 
>> track down the root of the problem:
>>
>>
>> 1- There was no issue up to 3.28. The reports appeared only on 3.30 and 
>> above.
>>
>> 2- I'm pretty sure that it occurs only on Windows, and only Win 11. Just now 
>> checked again on my Debian machine, with 3.36, and the problem does not 
>> appear, and never has.
>>
>> 3- Somehow I think this might be a Qt problem. Do you know if there were any 
>> Qt changes in Win installs between 3.28 and 3.30.x?
>
>
> Actually, if it works on a given platform, it's by accident and not design 😁. 
> There's no tests covering this and I don't think it's been actually thought 
> out by design.
>
> So my questions related to high level design decisions, like:
>
> - should the switch to rtl layout determined by the content of a label alone? 
> Or is it determined by the font choice? Or the users locale? Or should it be 
> an explicit choice set per layer, so that the project will appear
>
> In my opinion, by the content alone. Not font choice since many fonts have 
> glyphs in both RTL and LTR languages. Not user's locale, since a map can 
> contain text in different RTL languages even if the locale LANG setting is 
> Western LTR. Not by layer, since user's can have multiple text attributes 
> with text in different languages in each.  In full featured word processors 
> there is, of course, a button to choose text directionality on a 
> per-paragraph level. But I don't think implementing that is required for map 
> labels.
>
>
> identical when shared with a user using a different locale for their qgis?
> - how should mixed ltr and rtl string work? Should users be required to 
> manually insert rtl / ltr unicode markers?
>
> Traditionally that has been handled by the underlying bidi library. All the 
> problematic edge cases of (i.e. a period within a string of numbers should be 
> LTR but a period at the end of RTL language string should be assumed to be at 
> the end of the RTL string), are taken care of by that library. I'm pretty 
> sure this was the case with <=3.28.x. I wouldn't expect users to know how to 
> insert RTL unicode. We just switch the keyboard language.
>
>
> - how should rtl be handled with respect to multiline text alignment?
>
> Ideally, alignment (as opposed to RTL directionality) should be user 
> configurable. I believe you have already done this with the legend that 
> allows aligning legend items to the right or left.
>
> But, regarding map labels, a minimalist approach would be to always align RTL 
> text to the right, and LTR text to the left. (Don't let "perfect be the enemy 
> of good")
>
>
> - is rtl placement of characters determined by graphemes? Ie do we split the 
> string to graphemes and then lay these out right to left? Or is it done on 
> individual characters?
>
> Not sure I understand. But as above, the underlying bidi library should be 
> handling the cases of individual characters that might be RTL in some cases, 
> and LTR in others.
>
>
> Cheers
>
>
>
> Nyall
>>
>>
>> If I can be of any further help testing, let me know. i.e. I can update a 
>> colleague's machine, and prepare a very simple test project...
>>
>>
>> Best, Micha
>>
>>
>> On 28/05/2024 5:56, Nyall Dawson via QGIS-User wrote:
>>
>> Hi lists,
>>
>> I'm looking for some assistance in fixing the right-to-left labeling
>> issues described in https://github.com/qgis/QGIS/issues/54098 . While
>> I can fix the code issues, I don't have the linguistic understanding
>> to know how right-to-left text SHOULD behave in QGIS labels!
>>
>> Is there anyone out there from a RTL language background who can add
>> the missing information to the above ticket and help get this bug
>> fixed?
>>
>> Nyall
>> ___
>> QGIS-User mailing list
>> qgis-u...@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>>
>> --
>> Micha Silver
>> Ben Gurion Univ.
>> Sde Boker, Remote Sensing Lab
>> cell: +972-523-665918
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
___
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-user] Looking for assistance with fixing RTL label bugs

[Nyall Dawson via QGIS-Developer]

Hi Micha,


On Tue, 28 May 2024, 6:28 pm Micha Silver,  wrote

> Thanks for following up on this.
>
> The few details (that are mentioned in the issue tracker) that might help
> track down the root of the problem:
>
>
> 1- There was no issue up to 3.28. The reports appeared only on 3.30 and
> above.
>
> 2- I'm pretty sure that it occurs only on Windows, and only Win 11. Just
> now checked again on my Debian machine, with 3.36, and the problem does not
> appear, and never has.
>
> 3- Somehow I think this might be a Qt problem. Do you know if there were
> any Qt changes in Win installs between 3.28 and 3.30.x?
>

Actually, if it works on a given platform, it's by accident and not design
😁. There's no tests covering this and I don't think it's been actually
thought out by design.

So my questions related to high level design decisions, like:

- should the switch to rtl layout determined by the content of a label
alone? Or is it determined by the font choice? Or the users locale? Or
should it be an explicit choice set per layer, so that the project will
appear identical when shared with a user using a different locale for their
qgis?
- how should mixed ltr and rtl string work? Should users be required to
manually insert rtl / ltr unicode markers?
- how should rtl be handled with respect to multiline text alignment?
- is rtl placement of characters determined by graphemes? Ie do we split
the string to graphemes and then lay these out right to left? Or is it done
on individual characters?

Nyall

>
> If I can be of any further help testing, let me know. i.e. I can update a
> colleague's machine, and prepare a very simple test project...
>
>
> Best, Micha
>
>
> On 28/05/2024 5:56, Nyall Dawson via QGIS-User wrote:
>
> Hi lists,
>
> I'm looking for some assistance in fixing the right-to-left labeling
> issues described in https://github.com/qgis/QGIS/issues/54098 . While
> I can fix the code issues, I don't have the linguistic understanding
> to know how right-to-left text SHOULD behave in QGIS labels!
>
> Is there anyone out there from a RTL language background who can add
> the missing information to the above ticket and help get this bug
> fixed?
>
> Nyall
> ___
> QGIS-User mailing listqgis-u...@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
> --
> Micha Silver
> Ben Gurion Univ.
> Sde Boker, Remote Sensing Lab
> cell: +972-523-665918
>
>
___
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] Looking for assistance with fixing RTL label bugs

[Nyall Dawson via QGIS-Developer]

Hi lists,

I'm looking for some assistance in fixing the right-to-left labeling
issues described in https://github.com/qgis/QGIS/issues/54098 . While
I can fix the code issues, I don't have the linguistic understanding
to know how right-to-left text SHOULD behave in QGIS labels!

Is there anyone out there from a RTL language background who can add
the missing information to the above ticket and help get this bug
fixed?

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] Qt WebEngine in QGIS 3.36

[Nyall Dawson via QGIS-Developer]

On Mon, 27 May 2024, 11:02 pm Enrico Ferreguti,  wrote:

> Hi Nyall
> the installed qt webengine is the following:
>
> $ apt list --installed | grep webengine
> libqt5webengine-data/jammy,jammy,now 5.15.9+dfsg-1 all [installato,
> automatico]
> libqt5webengine5/jammy,now 5.15.9+dfsg-1 amd64 [installato]
> libqt5webenginecore5/jammy,now 5.15.9+dfsg-1 amd64 [installato, automatico]
> libqt5webenginewidgets5/jammy,now 5.15.9+dfsg-1 amd64 [installato,
> automatico]
> python3-pyqt5.qtwebengine/jammy,now 5.15.5-1 amd64 [installato, automatico]
> qml-module-qtwebengine/jammy,now
>

You need python qt webengine 5.15.6 for use in qgis. See
https://www.riverbankcomputing.com/static/Downloads/PyQtWebEngine/ChangeLog-5.15.7.dev2405031852

The required change is "Allow Qt.AA_ShareOpenGLContexts to be specified
before a
 QCoreApplication is created to allow PyQtWebEngineWidgets to be
 imported.".

I'd file a bug for your distro and request and update.

Nyall

5.15.9+dfsg-1 amd64 [installato]
> qtwebengine5-dev/jammy,now 5.15.9+dfsg-1 amd64 [installato]
> qtwebengine5-doc/jammy,jammy,now 5.15.9+dfsg-1 all [installato, automatico]
>
> Thanks for the support.
>
>
>
>
> Il giorno lun 27 mag 2024 alle ore 00:21 Nyall Dawson <
> nyall.daw...@gmail.com> ha scritto:
>
>> On Sun, 26 May 2024 at 18:42, Enrico Ferreguti via QGIS-Developer
>>  wrote:
>> >
>> > Dear QGIS developers, I would need your support to update my plugins.
>> >
>> > I read that Qt WebEngine, from QGIS
>> >
>> > 3.36.3-Maidenhead, QT 5.15.3, is available for plugins:
>> https://changelog.qgis.org/en/entry/2607
>>
>> Which version of the python webengine library is installed? I suspect
>> this package is out of date and needs an update.
>>
>> Nyall
>>
>> >
>> >
>> > But on Ubuntu Jammy LTS 22.04 and a fresh QGIS 3.36.3-Maidenhead with
>> QT 5.15.3, when I try to import from QT5:
>> > from PyQt5.QtWebEngineWidgets import QWebEngineView, QWebEnginePage,
>> >
>> > I get an exception:
>> > ImportError: QtWebEngineWidgets must be imported before a
>> QCoreApplication instance is created
>> >
>> > and when I do the same from python3 in bash I get no exceptions
>> >
>> > Where Am I wrong? Is there something different to do for importing
>> QtWebEngineWidgets ?
>> > Can you point me to a running example?
>> >
>> > Thank you very much.
>> > Enrico Ferreguti
>> >
>> >
>> > ___
>> > 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] Updating interfaces

[Nyall Dawson via QGIS-Developer]

On Mon, 27 May 2024, 5:54 pm Pedro Camargo via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hello fellow QGIS'ers.
>
> I have a (new to me) problem in my hands.
>
> I am building an interface to run a large transportation simulation model (
> Polaris ) from a
> QGIS plugin, and I would like to update the interface as the simulation
> progresses.
>
> The issue here is that this simulation is done inside a compiled C++
> executable from which I cannot emit any QT signals, so I have to do it
> "manually" by processing the logfile generated by the application.
>
> I currently don't see a way to do this, as the calling the simulation
> processes captures the GIL and I can't update the interface, but is there
> another way of doing this?
>
> I am at a bit of a loss, so I appreciate any pointers.
>

I'd suggest following the approach used by the GDAL processing algorithms.
See

https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/gdal/GdalUtils.py#L146

Nyall



> Cheers,
> Pedro
>
> ___
> 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] 3D Polygons in PYQGIS

[Nyall Dawson via QGIS-Developer]

On Fri, 24 May 2024 at 06:09, Jean Garcia via QGIS-Developer
 wrote:
>
> Good Afternoon,
>
>
>
> I am currently working on a project that generates a 3D image of a layer. Is 
> it still not possible to generate a 3D polygon through PYQGIS?

What exactly are you trying to do? There's many ways this request
could be interpreted.

(Maybe the "drape" tool from the processing toolbox does what you need?)

Nyall

>
> I have all the slope values, etc. I have also already made the polygon layers 
> which I want to convert to 3D.
>
> Been looking around and haven’t found any solutions that have been able to 
> help me so this is my last resort before I give up.
>
> FYI. I am on version 3.28. This being the case if it is allowed in newer 
> versions I would still wish to know.
>
>
>
> Many 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 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] Qt WebEngine in QGIS 3.36

[Nyall Dawson via QGIS-Developer]

On Sun, 26 May 2024 at 18:42, Enrico Ferreguti via QGIS-Developer
 wrote:
>
> Dear QGIS developers, I would need your support to update my plugins.
>
> I read that Qt WebEngine, from QGIS
>
> 3.36.3-Maidenhead, QT 5.15.3, is available for plugins: 
> https://changelog.qgis.org/en/entry/2607

Which version of the python webengine library is installed? I suspect
this package is out of date and needs an update.

Nyall

>
>
> But on Ubuntu Jammy LTS 22.04 and a fresh QGIS 3.36.3-Maidenhead with QT 
> 5.15.3, when I try to import from QT5:
> from PyQt5.QtWebEngineWidgets import QWebEngineView, QWebEnginePage,
>
> I get an exception:
> ImportError: QtWebEngineWidgets must be imported before a QCoreApplication 
> instance is created
>
> and when I do the same from python3 in bash I get no exceptions
>
> Where Am I wrong? Is there something different to do for importing 
> QtWebEngineWidgets ?
> Can you point me to a running example?
>
> Thank you very much.
> Enrico Ferreguti
>
>
> ___
> 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] High load on plugins.qgis.org

[Nyall Dawson via QGIS-Developer]

On Wed, 15 May 2024 at 09:33, Greg Troxel via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
>   [high plugin load]
>
> Three suggestions:
>
>   is this a distributed problem, or a few abusive addresses?  In
>   openstreetmap I think they would just firewall the addresses in
>   questio.
>
>   please don't use google recapcha or anything else without stellar
>   privacy policies

Does recaptcha even do ANYTHING anymore?  (apart from making us all train
Google's machine learning tools... 😱). I suspect the rise of chatgpt et al
has made their "protections" meaningless.

Nyall


>
>   consider rate-limiting IP addresses instead, 1s delay for a few, then
>   30s or something like that.
> ___
> 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] Request for Commit Privileges to QGIS

[Nyall Dawson via QGIS-Developer]

On Wed, 10 Apr 2024, 7:40 pm Joona Laine via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Dear QGIS developers!
>
> Hope you're all doing well!. My name is Joona Laine, and I've been making
> many contributions to the QGIS project under the GitHub username
> "Joonalai." during the past few years. I am also the author and main
> contributor of the projects pytest-qgis and flake8-qgis.
>
> Having read through the "Requirements for new contributors" requirements
> and agreeing to them all, I'm writing to formally request commit privileges
> to the QGIS repository. I believe these privileges would enable me to
> contribute more effectively to the project's ongoing development.
>
> I'm committed to upholding the project's standards and guidelines, and I'm
> eager to take on a more active role in advancing the QGIS project. I'm
> prepared to fulfill any additional requirements or steps necessary to
> facilitate this process.
>
> Thank you for considering my request. I look forward to your response and
> the opportunity to continue contributing to the QGIS community.
>

Hi Joona!

First off, thank you for your contributions to QGIS! They are certainly
valued and highly appreciated.

Can you explain a little more about why you desire commit rights to the
QGIS repo, and why this can't be met via pull requests?

Unfortunately, in the light of the recent xz hacking mess, I think the QGIS
project needs to be **extremely** cautious about granting additional rights
to **anyone** for the repositories, and treat this as an extreme measure
only done when absolutely necessary. It's the sad reality of the world we
currently live in. ☹️

Nyall



Best regards,
>
> Joona Laine
> ___
> 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] Signals and QtDesigner

[Nyall Dawson via QGIS-Developer]

On Fri, 1 Mar 2024, 5:02 am Jorge Tornero via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hello all,
>
> I write the list because I have a a simple question (currently I'm trying
> to tackle issue #56275 Improve Parsing of Data from Serial Port Sensors).
>
> Is  using the QtDesigner signal/slot assignment facilities discouraged?
> I've read this in the QGIS coding standards guide and don't really know if
> that means that:
>
> *Avoid use of Qt auto connect slots (i.e. those named void
> on_mSpinBox_valueChanged).*
>
> So, If I need to connect two widgets in a groupBox (a radioButton and a
> QLineEdit, just to enable the QLineEdit only a determinate radioButton is
> selected), should I make it programatically instead using QtDesigner?
>

I realise you posted a follow up, but just to confirm -- yes, do NOT rely
on connections made in the designer.

The rationale is that the designer can break these connections without any
warning. Eg if you cut and paste some widgets to move them around, any
connections to those will be silently broken. It's much safer to rely on
manual connections with compile time checks...

Nyall

>
>
> Thanks a lot
>
> Jorge
> ___
> 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] [Qgis-psc] Official PSC call on pull request policies

[Nyall Dawson via QGIS-Developer]

On Wed, 28 Feb 2024 at 08:49, Marco Bernasocchi  wrote:

> Thanks Nyall, thanks Sandro,
>
> Just a quick question, is the
>  -is:draft
> Filter an option at all? I guess it does not reduce the n/r by default but
> could help?
>
> https://github.com/qgis/QGIS/pulls?q=is%3Apr+is%3Aopen+-is%3Adraft
>

That hides them, yes. But the bigger question remains as to what value
having unfinished work in the queue has in the first place. In my opinion
if it's not ready for review and merge, it's not actually a "pull REQUEST"
and just doesn't belong there. In my proposal there's already mention that
short term pull requests can be permitted for the express purpose of
performing a CI test run, so after that why is there a need to allow
unfinished work to remain in the queue?

If the need is for others to see and be exposed to unfinished work, then
let's look at an extreme example: I have some 100's of branches of work in
an unfinished state on my QGIS fork, from proof of concept experiments
through to things which I just don't think work well enough to be
submitted. Should all of those draft/wip branches be pull requests in the
QGIS repo? 🤣 If the justification for allowing draft/wip requests is that
others can see what's being/been done, then I guess the same argument would
apply to all of this.

Nyall


>
>
> Cheers Marco
>
>
> On Tue, 27 Feb 2024, 23:09 Sandro Santilli via QGIS-PSC, <
> qgis-...@lists.osgeo.org> wrote:
>
>> Thanks Nyall for raising this thread!
>>
>> On Mon, Feb 26, 2024 at 09:21:05AM +1000, Nyall Dawson wrote:
>>
>> > Policy #1: https://github.com/qgis/QGIS/pull/56062
>> >
>> > In short, Sandro proposes that the pull request queue be an open queue
>> > of ALL work happening everywhere, in any state of completeness. Pull
>> > requests are permitted for semi-complete work, and for long-term
>> > (including multi-year) projects which are not yet ready for review or
>> > merge. The justification here is that having this work open in the
>> > queue makes it widely visible and so that other developers are aware
>> > of ongoing work across the community.
>>
>> I would add that allowing long-term PRs also serves the purpose of making
>> it easy for contributors to check the state of their work against CI as
>> running tests locally is so hard that I dubt anyone is doing that.
>>
>> > Policy #2: https://github.com/qgis/QGIS/pull/56523
>>
>> [...]
>>
>> > When the queue includes work which is not ready for review, then it
>> > becomes very tricky to work out the actual status of pull requests and
>> > which ones should be focused on during review time.
>>
>> I think this is a limitation of the software used to get the list
>> of pull requests needing focus, and should be threated as such.
>> If github makes it hard to filter on "PR state" we could use a label
>> to do that.
>>
>> --strk;
>> ___
>> 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] Finishing Visual Changelog for export to site

[Nyall Dawson via QGIS-Developer]

On Wed, 28 Feb 2024 at 02:55, Richard Duivenvoorde 
wrote:

> On 2/27/24 8:17 AM, Nyall Dawson wrote:
> > Hmm, would it be possible to do the export again? I noticed a few extra
> entries were added overnight too, and these aren't present on the site.
> (Plus a few wording improvements I made this morning too)..
>
> Yep, no problem. Please let me know
>

This should be good to re-export, I've deleted all the junk backport
entries from 3.36 on changelog.qgis now.

Thanks!
Nyall


>
> Richard
>
___
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] Finishing Visual Changelog for export to site

[Nyall Dawson via QGIS-Developer]

On Tue, 27 Feb 2024 at 17:13, Nyall Dawson  wrote:

>
>
> On Tue, 27 Feb 2024, 5:06 pm Richard Duivenvoorde via QGIS-Developer, <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Hi,
>>
>> Moved changelog to site:
>>
>> https://qgis.org/en/site/forusers/visualchangelog336/index.html
>
>
Hmm, would it be possible to do the export again? I noticed a few extra
entries were added overnight too, and these aren't present on the site.
(Plus a few wording improvements I made this morning too)..

Nyall



>
>>
>> Do we want the Backports in it?
>> I already removed all the lines:
>> "This feature was developed by `qgis-bot > >`__"
>>
>> But now it is, without context or images, very raw.
>>
>> Same question about the 'Feature: Revert “Restore default metadata from
>> DB”'-like items.
>>
>
> They definitely shouldn't be in there. Something has gone amiss with the
> changelog harvester, I noticed it's put a bunch of entries in overnight
> which weren't even present in 3.36 😱
>
> Nyall
>
>
>> If we need more time to add stuff, let me know.
>>
>> Regards,
>>
>> Richard Duivenvoorde
>>
>>
>> On 2/23/24 3:40 PM, Richard Duivenvoorde via QGIS-Developer wrote:
>> > Hi Devs,
>> >
>> > As release 3.36 Maidenhead is near...
>> >
>> > Please have a look at https://changelog.qgis.org/en/qgis/version/3.36/
>> >
>> > To fix/polish or add stuff you did or is important to show to users.
>> >
>> > @Andreas: I'll wait for you to add the tables with notable changes,
>> please ping me when done
>> >
>> > Then I will dump it to rst and include it in the website (probably for
>> the last time, as hopefully we will have a new website next release :-)  ).
>> >
>> > Thanks in advance,
>> >
>> > 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
>>
>> ___
>> 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] Finishing Visual Changelog for export to site

[Nyall Dawson via QGIS-Developer]

On Tue, 27 Feb 2024, 5:06 pm Richard Duivenvoorde via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hi,
>
> Moved changelog to site:
>
> https://qgis.org/en/site/forusers/visualchangelog336/index.html
>
> Do we want the Backports in it?
> I already removed all the lines:
> "This feature was developed by `qgis-bot `__"
>
> But now it is, without context or images, very raw.
>
> Same question about the 'Feature: Revert “Restore default metadata from
> DB”'-like items.
>

They definitely shouldn't be in there. Something has gone amiss with the
changelog harvester, I noticed it's put a bunch of entries in overnight
which weren't even present in 3.36 😱

Nyall


> If we need more time to add stuff, let me know.
>
> Regards,
>
> Richard Duivenvoorde
>
>
> On 2/23/24 3:40 PM, Richard Duivenvoorde via QGIS-Developer wrote:
> > Hi Devs,
> >
> > As release 3.36 Maidenhead is near...
> >
> > Please have a look at https://changelog.qgis.org/en/qgis/version/3.36/
> >
> > To fix/polish or add stuff you did or is important to show to users.
> >
> > @Andreas: I'll wait for you to add the tables with notable changes,
> please ping me when done
> >
> > Then I will dump it to rst and include it in the website (probably for
> the last time, as hopefully we will have a new website next release :-)  ).
> >
> > Thanks in advance,
> >
> > 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
>
> ___
> 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] Finishing Visual Changelog for export to site

[Nyall Dawson via QGIS-Developer]

On Sun, 25 Feb 2024 at 17:47, Richard Duivenvoorde  wrote:
>
> I do not want to stress people, I just wanted to let people know.
>
> Just ping me here.

Thanks, I'm all done now! I've sent through my bug fixes to Andreas too.

Nyall

>
> Regards,
>
> Richard Duivenvoorde
>
> On 2/25/24 01:51, Mathieu Pellerin wrote:
> > Same here, I'd appreciate a day
> >
> > On Sun, Feb 25, 2024, 03:24 Nyall Dawson via QGIS-Developer 
> > mailto:qgis-developer@lists.osgeo.org>> 
> > wrote:
> >
> >
> >
> > On Sat, 24 Feb 2024, 12:41 am Richard Duivenvoorde via QGIS-Developer, 
> > mailto:qgis-developer@lists.osgeo.org>> 
> > wrote:
> >
> > Hi Devs,
> >
> > As release 3.36 Maidenhead is near...
> >
> > Please have a look at 
> > https://changelog.qgis.org/en/qgis/version/3.36/ 
> > <https://changelog.qgis.org/en/qgis/version/3.36/>
> >
> > To fix/polish or add stuff you did or is important to show to users.
> >
> >
> > Could I have a day to polish off my entries please? 🙏
> > Nyall
> >
> >
> > @Andreas: I'll wait for you to add the tables with notable changes, 
> > please ping me when done
> >
> > Then I will dump it to rst and include it in the website (probably 
> > for the last time, as hopefully we will have a new website next release :-) 
> >  ).
> >
> > Thanks in advance,
> >
> > Richard Duivenvoorde
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org 
> > <mailto:QGIS-Developer@lists.osgeo.org>
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> > <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> > Unsubscribe: 
> > https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> > <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org <mailto:QGIS-Developer@lists.osgeo.org>
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> > <https://lists.osgeo.org/mailman/listinfo/qgis-developer>
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 
> > <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] GDAL processing algorithms issues due the default output layer extensions weirdly changed

[Nyall Dawson via QGIS-Developer]

On Mon, 26 Feb 2024 at 08:58, Andrea Giudiceandrea via QGIS-Developer
 wrote:
>
> Hi developers,
> various QGIS users have reported during the latest months (mostly since
> September 2023, and a couple also back in July 2023) on various channels
> a strange issue which makes the GDAL processing algorithms to fail when
> the temporary output is set.
>
> Looking at the provided processing logs, it turns out that the issue is
> due to the fact that the default output vector layer extension was set
> to .xtf "Interlis 2" (instead of the default .gpkg "GeoPackage") or that
> the default output raster layer extension was set to .nc "NetCDF"
> (instead of the default .tif "GeoTIFF").
>
> The weird think is that all the users affected by the issue have
> reported that they had not deliberately changed these settings.

Hmm, I wonder if it's a plugin changing this setting. I've definitely
seen plugins before doing unfriendly things like this...

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] Official PSC call on pull request policies

[Nyall Dawson via QGIS-Developer]

Hi PSC,

I would love for an official call to be made on which of two
conflicting pull request queue management policies should be adopted
by QGIS.

There are currently two proposals, and the lack of a formal policy is
causing confusion/conflict in how pull requests are managed.

Policy #1: https://github.com/qgis/QGIS/pull/56062

In short, Sandro proposes that the pull request queue be an open queue
of ALL work happening everywhere, in any state of completeness. Pull
requests are permitted for semi-complete work, and for long-term
(including multi-year) projects which are not yet ready for review or
merge. The justification here is that having this work open in the
queue makes it widely visible and so that other developers are aware
of ongoing work across the community.

Currently, these pull requests will be auto-closed by stalebot due to
the lack of activity on the ticket. Sandro's proposal is to disable
stalebot handing of draft / WIP pull requests, and effectively to
formalise that the queue is a valid place for work of this nature and
status.

(@strk please expand here if you feel I haven't summarised your point
of view correctly!)

Policy #2: https://github.com/qgis/QGIS/pull/56523

In this PR I propose to set a formal policy that draft and WIP pull
requests are NOT suitable for opening against the QGIS repository.

My justification is that we have a long-standing issue with
maintainability of the pull request queue, and anything which
decreases the signal-to-noise ratio on open tickets is undesirable.
When the queue includes work which is not ready for review, then it
becomes very tricky to work out the actual status of pull requests and
which ones should be focused on during review time. (Effectively right
now we have a situation where any pull request which is pushed on the
2nd page of requests will basically NEVER get reviewed, as there is a
constant stream of ready-for-review work flowing into the first page
and the signal-to-noise ratio of ready-for-review/merge PRs on
subsequent pages is extremely low). I do not believe it is fair for
submissions like https://github.com/qgis/QGIS/pull/55172 or
https://github.com/qgis/QGIS/pull/55293 where reviews take SUCH a long
time, and it is my belief that by keeping the queue as small as
possible and avoiding WIP/draft work we will increase the likelihood
that PRs like these can be reviewed more quickly in future.

Please note that there is considerable discussion on
https://github.com/qgis/QGIS/pull/56062 already which should be read
when reviewing this decision.

Can I ask that PSC choose one of these two policies to formally adopt
so that there is no misunderstanding or conflict in future?

Thanks in advance!
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] Finishing Visual Changelog for export to site

[Nyall Dawson via QGIS-Developer]

On Sat, 24 Feb 2024, 12:41 am Richard Duivenvoorde via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hi Devs,
>
> As release 3.36 Maidenhead is near...
>
> Please have a look at https://changelog.qgis.org/en/qgis/version/3.36/
>
> To fix/polish or add stuff you did or is important to show to users.
>

Could I have a day to polish off my entries please? 🙏
Nyall


> @Andreas: I'll wait for you to add the tables with notable changes, please
> ping me when done
>
> Then I will dump it to rst and include it in the website (probably for the
> last time, as hopefully we will have a new website next release :-)  ).
>
> Thanks in advance,
>
> 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
>
___
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] GSoC 2024 proposal : QGIS improve the graphical modeler UI and UX

[Nyall Dawson via QGIS-Developer]

On Thu, 22 Feb 2024 at 17:38, Valentin BUIRA via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> Hi qgis developers
>
> My name is Valentin Buira, I'm a french student in urban planning and I'm
interested in participating in this year Google Summer of Code to improve
the graphical modeler.
>
> In particular I am interested in improving the user interface(UI) and
user experience (UX) of the graphical modeler based on my previous
experience with other node-based applications. If you are familiar with
Blender the inspiration will be obvious to you but I tried to adapt to the
identity and features of Qgis like the expression engine.
>
> You can find the proposal at the url :
https://docs.google.com/document/d/1iXHMTylTHLljfHBITfuIfJzi4_4hpQifEvj5GkM8OCc/edit?usp=sharing
>
> So far I am happy with my proposal but I'm looking for feedback and
suggestions, and also tips on the technical feasibility and the schedule of
the proposal.

Hi Valentin!

Just to start with, this looks great and it's really exciting to see
someone take this on!

I do have a couple of suggestions for you before finalising your proposal:

- I'd suggest cutting back on the scope here. There's a LOT of work here,
and a lot of complexity. I'd strongly recommend dropping the extra "quality
of life" improvements from your proposal in order to keep your life sane!
(As a bit of a hint, take for example "A unified list for every node". I
wrote a lot of this code and I would estimate it would take me at least 2
days to do this change, and that's with decades of experience in c++, Qt
and the Qt model classes. I just don't think it's realistic that this could
be done in the same week as testing + other things). You could easily drop
the quality of life changes and still have a very compelling proposal.

- Be aware upfront that there's a lot of complexity in the model design and
widget handling. In early 3.x releases ALL of this code was done in Python,
and there were Python based interfaces for plugins to expose custom widgets
for algorithm parameters. Because of stable API restriction, we CAN'T break
those interfaces and as a result the current code is a complex interplay of
c++ underlying bits with Python glue on top to keep the old interfaces
working as originally designed. It's not pretty at all, but unfortunately
it can't be cleaned up prior to 4.0 when we can safely remove the old
interfaces. Suffice to say, there's going to be a LOT of head scratching
when reading over this code and trying to understand how it works
together. 🙀

- Something to consider in your UI designs is that there's two different
"types" of expression based values for parameters. One (which you've
already covered) is the "precalculated expression" type, where an
expression is evaluated once before running the tool and the result used as
the value for that parameter. The other is "data defined" parameter values,
where the parameter value is evaluated (or taken from a field) once for
every feature passing through the algorithm. These are distinct, different
concepts, and care will need to be taken to expose them as such in a
user-friendly way.

- Care would need to be taken in handling existing models. I think the new
interface would have to be opt-in, as the visual arrangement of models
often takes a lot of work and there's definitely users out there who have
spent considerable time in arranging their models in a logical way. If we
force everyone to use a new visual form for the designer where algorithm
blocks are different sizes and the flow appears different, it will be quite
frustrating for these users.

Do you already have a mentor planned for this work?

Nyall

>
> On a side note, I will be attending the local code sprint in Grenoble the
26 mars. Where I will also discuss this proposal in person.
>
> Best regards,
> Valentin Buira
>
>
> ___
> 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] Backporting qt6 sip bindings to 3.34?

[Nyall Dawson via QGIS-Developer]

On Sat, 10 Feb 2024 at 09:07, Nyall Dawson  wrote:
>
> Hey list,
>
> What does everyone think about us backporting the python/PyQt6/ directory 
> from master to the 3.34 branch? I'm thinking we could do this as 
> "orphan"/unused files, with the intention that it would make backporting to 
> this branch easier. Obviously it introduces a bunch of "noise" in the repo 
> for this branch.
>
> Right now any change to a header which entails an accompanying change to the 
> .sip files will not be backportable without merge conflicts, so eg the 
> backport bot is rather gutless right now...

Ok, done in https://github.com/qgis/QGIS/pull/56324

Nyall

>
> 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] Another (final?) qt6 progress catchup?

[Nyall Dawson via QGIS-Developer]

Hi lists,

I'm thinking it's probably time for another (and perhaps the final?!) Qt 6
progress/planning meeting.

Is anyone else interested?

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] Backporting qt6 sip bindings to 3.34?

[Nyall Dawson via QGIS-Developer]

Hey list,

What does everyone think about us backporting the python/PyQt6/ directory
from master to the 3.34 branch? I'm thinking we could do this as
"orphan"/unused files, with the intention that it would make backporting to
this branch easier. Obviously it introduces a bunch of "noise" in the repo
for this branch.

Right now any change to a header which entails an accompanying change to
the .sip files will not be backportable without merge conflicts, so eg the
backport bot is rather gutless right now...

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] Qt6 builds and plugins -- ready for testing!

[Nyall Dawson via QGIS-Developer]

On Wed, 7 Feb 2024 at 18:10, Alessandro Pasotti  wrote:
>
> Hi Nyall,
>
> This is great news, thank you all for the efforts.
>
> There was a budget available for QT6 releases so I think it shouldn't
> be a problem,  as long as the CI tests pass on QT6 we can make the
> experimental builds available for testing.

Well, we're not at 100% pass rate on CI tests on Qt 6 just yet 😁. I'd
estimate there's about a one week effort left to get the remainder of these
passing.

But it's at a stage where I'm confident that the majority of the remaining
disabled tests have Python specific issues we need to fix, and that they
aren't related to underlying c++ issues on the Qt 6 builds.

Nyall


>
>
>
> On Wed, Feb 7, 2024 at 6:10 AM Nyall Dawson via QGIS-Developer
>  wrote:
> >
> > On Fri, 26 Jan 2024 at 07:58, Nyall Dawson 
wrote:
> > >
> > > Hi list,
> > >
> > > With some excellent work recently completed by Julien, we're now at a
stage where there's no *major* roadblocks preventing plugins from
functioning under the Qt6 builds!
> >
> > OK, given the progress made over the last couple of weeks I feel like
> > we're in a position now where we could start making Qt6 based "preview
> > releases" available for widespread testing.  How do we feel about
> > making non-default, non-recommended Qt6 preview releases of QGIS 3.36
> > publicly available? Is there any particular milestone we need to
> > achieve before we should consider this?
> >
> > 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
>
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   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

Re: [QGIS-Developer] Qt6 builds and plugins -- ready for testing!

[Nyall Dawson via QGIS-Developer]

On Fri, 26 Jan 2024 at 07:58, Nyall Dawson  wrote:
>
> Hi list,
>
> With some excellent work recently completed by Julien, we're now at a stage 
> where there's no *major* roadblocks preventing plugins from functioning under 
> the Qt6 builds!

OK, given the progress made over the last couple of weeks I feel like
we're in a position now where we could start making Qt6 based "preview
releases" available for widespread testing.  How do we feel about
making non-default, non-recommended Qt6 preview releases of QGIS 3.36
publicly available? Is there any particular milestone we need to
achieve before we should consider this?

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] Theoretical discussion: A QGIS paid plugin marketplace? (was: sponsored plugin)

[Nyall Dawson via QGIS-Developer]

Hi lists!

I wanted to kick start a (hopefully!) civil, THEORETICAL discussion about
the role of a paid plugin marketplace for QGIS plugins.

This has been on my mind for a while, and recently was bumped by this email
to the list:

On Fri, 19 Jan 2024 at 19:38, gam17--- via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> Hi everyone,
> like many of you, I have developed and maintained a plugin for many
> years completely free of charge.
> I have never received any donation or compensation of any kind and now I
> would like to find a solution.
> Has anyone already found a way to receive donations?
> I was thinking of asking for a sponsor that would be displayed during
> execution, for example in the window titles or through a specific menu
> item like QGIS does (in this way the sponsor would be much less
> visible).

So again, stressing that this is a THEORETICAL discussion, I'm interested
in hearing people's thoughts on the potential role of a paid plugin
marketplace for QGIS.

Here's a bullet point dump of where I'm currently sitting:

- Yes, I'm aware that plugins must be GPL, and that this makes paid plugins
a little trickier in that they're obviously still subject to the GPL.
- The GPL does NOT prevent charging for software, or mandate making it
public to non-paying customers. We could potentially have GPL plugins which
are only available to paid users, and only make these plugins available
privately to those users. YES, the GPL **DOES** mean that those paying
customers can redistribute the plugin publicly and freely without issue if
they want (and regardless of whether the original developer wants!)
- In fact, there's already likely thousands of private, paid for plugins
out there! I'm talking here of plugins made specifically for internal use
by one organisation only. Yep, that organisation COULD make the plugin
public/freely available, but in many cases they are specific to that one
organisation's needs or contain organisation sensitive logic/data. These
plugins are completely compliant with the GPL, despite being private and
paid for by that organisation.
- There's nothing preventing a public GPL QGIS plugin from depending on a
subscription based back-end, and offering zero value to anyone not paying
for that backend. And there's a growing number of these plugins, which
depend on users paying xxx large corporate entity regular high fees to
access the backend service. The GPL doesn't (and arguably
shouldn't) prevent these large entities from making money off QGIS plugins.
- But this means that the current situation is unfairly weighted toward
these large entities! A one-person team making an excellent plugin and
providing an awesome tool for use in QGIS has a MUCH MUCH harder time
finding ANY financial compensation for their efforts! I don't like this
situation at all, and I'd say it goes against the "spirit" of why QGIS was
made under the GPL in the first place. The big corporate entities win, the
smaller community focused developers lose out. 👎
- Despite the fact that a paid user could freely re-distribute a paid-for
plugin, there's still potential financial gain for the developer in making
a plugin available for a charge on a theoretical QGIS plugin marketplace.
- The blender market is a great example of this. There's LOTS of GPL
blender add ons available there at charge. Eg
https://blendermarket.com/products/hard-ops--boxcutter-ultimate-bundle?num=2&src=top
as one example. If those numbers are accurate, that developer has sold >35k
copies of a GPL licensed add on at $39 each. I'm going to go out on a limb
here and guess that that developer's motivation to make their add-on
excellent is considerably higher than the developer of an equivalent QGIS
plugin 🤣 (not to mention that their time investment is much more
justifiable). And any ONE of those 35k paid users could have made the
plugin freely available for everyone else... but that hasn't stopped the
sales.

So what does everyone else think? Would there be a THEORETICAL place for a
THEORETICAL paid QGIS plugin marketplace somewhere in the future? Or is
there a better model we could (theoretically 🤪) follow to financially
reward plugin developers?

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] Qt6 builds and plugins -- ready for testing!

[Nyall Dawson via QGIS-Developer]

On Sat, 27 Jan 2024 at 07:53, Richard Duivenvoorde via QGIS-Developer
 wrote:
>
> Ok, installed qwt by downloading deb file from testing...
>
> configure: ok
> generate: ok
>
> compiling: stopped at
> build/python/gui/gui.sip: line 11: column 9: 'QtCore/QtCoremod.sip' could not 
> be found
> seems to be able to fix this using the fix from Thomas from
> https://github.com/qgis/QGIS/issues/54184#issuecomment-1795204001
> (NOTE: had to do this for my own build in Trixie too!)
>
> compile again: stop at:
>
> [423/2971] Building CXX object 
> src/core/CMakeFiles/qgis_core.dir/qgsvariantutils.cpp.o
> FAILED: src/core/CMakeFiles/qgis_core.dir/qgsvariantutils.cpp.o
> ...
> home/richard/git/qgisqt6/src/core/qgsvariantutils.cpp: In static member 
> function ‘static QVariant::Type 
> QgsVariantUtils::metaTypeToVariantType(QMetaType::Type)’:
> /home/richard/git/qgisqt6/src/core/qgsvariantutils.cpp:489:21: error: 
> ‘Float16’ is not a member of ‘QMetaType’
>489 | case QMetaType::Float16:
>| ^~~
> [440/2971] Building CXX object 
> src/core/CMakeFiles/qgis_core.dir/qgsvectorfilewriter.cpp.o
>
> Anybody a hint?

Looks like you'll need https://github.com/qgis/QGIS/pull/56033 too.
Try removing that line for now.

Nyall

>
> Regards,
>
> Richard Duivenvoorde
>
>
> On 1/26/24 10:05, Richard Duivenvoorde via QGIS-Developer wrote:
> > Whow! Cool!
> >
> > Thanks to all peeps/sponsors making this happen!
> >
> > Eager to try to build. Is
> > https://lists.osgeo.org/pipermail/qgis-developer/2022-August/065012.html
> > more or less the status of dependencies you also have to get/build yourself 
> > on Debian?
> >
> > Ok searched and tried to configure.
> >
> > Following seem to be OK:
> >
> > - qca  (I see libqca-qt6-dev/testing 2.3.8-1 in Debian testing)
> > - qtkeychain  (I see qtkeychain-qt6-dev/testing 0.14.2-1 in Debian testing)
> > - QScintilla  (I see libqscintilla2-qt6-dev/testing,now 2.14.1+dfsg-1 in 
> > Debian testing)
> >
> > - qwt  (cannot find qt6 mention in Debian testing)
> >
> > So: need to compile QWT myself?
> > Like mentioned in dev list mail from 2022?
> >
> >
> > For debianista's willing to try:
> > - on Debian testing, on which I also compile QGIS-qt5, I (via trial and 
> > error) installed:
> >
> > sudo apt install libqca-qt6-dev qtkeychain-qt6-dev libqscintilla2-qt6-dev 
> > qt6-serialport-dev qt6-svg-dev qt6-positioning-dev libqt6core5compat6 
> > qt6-5compat-dev python3-pyqt6 python3-pyqt6.qsci pyqt6-dev-tools 
> > python3-pyqt6.qtmultimedia qml6-module-qtmultimedia qt6-multimedia-dev 
> > qt6-tools-dev
> >
> > mkdir build;cd build;ccmake -GNinja -DBUILD_TESTING=FALSE 
> > -DENABLE_TESTS=OFF -DWITH_SERVER=FALSE -DWITH_3D=FALSE 
> > -DCMAKE_INSTALL_PREFIX=~/bin/qgis_/qt6/debug -DWITH_QWTPOLAR=OFF 
> > -DCMAKE_BUILD_TYPE=Debug -DWITH_GRASS=FALSE -DBUILD_WITH_QT6=TRUE 
> > -DWITH_OAUTH2_PLUGIN=FALSE -DWITH_WITH_SERVER_PLUGINS=OFF 
> > -DWITH_STAGED_PLUGINS=OFF -DWITH_PDAL=OFF -DWITH_QTWEBKIT=OFF ..
> >
> > Then configuring goes without errors.
> > But on generating, I get
> >
> >   CMake Error: The following variables are used in this project, but they 
> > are set to NOTFOUND.
> >   Please set them or make sure they are set and tested correctly in the 
> > CMake files:
> >   QWT_LIBRARY
> >   linked by target "qgis_gui" in directory 
> > /home/richard/git/qgisqt6/src/gui
> >   linked by target "qgis_app" in directory 
> > /home/richard/git/qgisqt6/src/app
> >   Generating done (0.5s)
> >
> > So probably need to get QWT compiled for qt6?
> > Found https://packages.debian.org/experimental/libqwt-qt6-6.2 but dare not 
> > to pull that into my testing machine?
> >
> >
> > Anyway, Thanks all!
> >
> > Regards,
> >
> > Richard Duivenvoorde
> >
> >
> > For debianista's willing to try:
> > - on Debian testing, on which I also compile QGIS-qt5, I (via trial and 
> > error) installed:
> >
> > sudo apt install libqca-qt6-dev qtkeychain-qt6-dev libqscintilla2-qt6-dev 
> > qt6-serialport-dev qt6-svg-dev qt6-positioning-dev libqt6core5compat6 
> > qt6-5compat-dev python3-pyqt6 python3-pyqt6.qsci pyqt6-dev-tools 
> > python3-pyqt6.qtmultimedia qml6-module-qtmultimedia qt6-multimedia-dev 
> > Qt6UiToolsConfig.cmake
> >
> > mkdir build;cd build;ccmake -GNinja -DBUILD_TESTING=FALSE 
> > -DENABLE_TESTS=OFF -DWITH_SERVER=FALSE -DWITH_3D=FALSE 
> > -DCMA

[QGIS-Developer] Qt6 builds and plugins -- ready for testing!

[Nyall Dawson via QGIS-Developer]

Hi list,

With some excellent work recently completed by Julien, we're now at a stage
where there's no *major* roadblocks preventing plugins from functioning
under the Qt6 builds!

In fact, the first plugin has already been ported to be compatible with
these (First Aid Plugin) -- see
https://github.com/wonder-sk/qgis-first-aid-plugin/commits/master/ .

I think we're now at a stage where wider testing of the Qt6 builds and
feedback via bug reports are valuable. A couple of notes:

- We're up to roughly 2/3rd of the existing Python tests passing on Qt 6
builds. That's obviously not everything, so we aren't finished with this
work yet 😁

- There's a script available in the repo for automatically upgrading QGIS
plugins/scripts to Qt 6 compatibility WITHOUT BREAKING compatibility with
older releases/qt5 based releases. It's here:
https://github.com/qgis/QGIS/blob/master/scripts/pyqt5_to_pyqt6/pyqt5_to_pyqt6.py

- After running the script, you'll also need to add "supportsQt6=yes" to
your plugins metadata configuration. Otherwise the Qt6 builds will just
ignore your plugin and will refuse to load it. See eg
https://github.com/wonder-sk/qgis-first-aid-plugin/commit/3687be7d9e026c59c9b775caaf5ee18cf8639886

- You'll need to compile your own Qt 6 build. There's no nightlies or any
prepackaged versions available.

- There are still some known issues with enum handling, but please open bug
reports when you encounter these!

- The plugin manager is currently broken in the Qt6 builds. Use a Qt5 build
to enable plugins
🤣

Again, to reiterate, there's NO plans for moving to QGIS 4.0 on the
horizon. The plan is to allow plugins to add Qt6 support without breaking
any compatibility with Qt5/older releases, so that the effort required by
plugin authors is extremely minimal. And with any luck,
the pyqt5_to_pyqt6.py script will do 99% of the work for you. Qt 6 builds
of QGIS 3.x will become available at some stage in a "preview release"
capacity, and likely some platforms will move to Qt6 only releases when
necessary for that platform (eg MacOS, wayland only linux systems). Read
more about the plan at
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/198

This work has ONLY been possible thanks to funding from qgis.org, ie it's
possible only because of the users and organisations sponsoring QGIS!

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] Adding a "solution proposed" label?

[Nyall Dawson via QGIS-Developer]

Hey all,

What do we think about adding a new label for GitHub tickets for "solution
proposed"? This could be used for tickets like
https://github.com/qgis/QGIS/issues/55871 where the issue is likely a user
error and a potential solution has been suggested.

Stale bot could auto close these like it does with feedback tickets.

It seems wrong to just close that issue without giving the reporter time to
reply, but at the same time it's highly likely to become just another
invalid open ticket if it's not actively managed in some way...

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] Strange Mysql (spatial) behaviour: no points visible

[Nyall Dawson via QGIS-Developer]

On Wed, 17 Jan 2024 at 06:15, Alessandro Pasotti via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Hi Richard,
>
> sorry, no hints except to check the logs and the QGIS dev tools query
> logger: is there anything suspicious?
>

There's a LOT of open bugs relating to mysql data -- eg
https://github.com/qgis/QGIS/issues/34170 . I suspect it's very rarely
used, and there's either a bug in GDAL or some special handling which needs
adding to QGIS to get this to work.

Perhaps something we could focus on during the upcoming 3.36 bug fix sprint?

Nyall



>
> On Tue, Jan 16, 2024 at 8:08 PM Richard Duivenvoorde via
> QGIS-Developer  wrote:
> >
> > No hints :-) ?
> >
> > I now have a live connection to the db, and can reproduce the issue here
> in master on Linux too.
> >
> > It's really strange: have a local db, I can even copy features from the
> attribute table to my local table, and THEN they show up
> >
> > ogrinfo shows exactly the same information of the db ( using -so).
> >
> > coordinates are fine too:
> >
> > select coord, ST_AsWKT(coord) from tblQgisProjecten tqp limit 1
> >
> > coord|ST_AsWKT(coord)
>  |
> >
> -++
> > POINT (168937.186906043 175180.302889316)|POINT(168937.186906043
> 175180.302889316)|
> >
> > could it be in char encoding, or in a strange attribute value? We
> already tried to create a simple view with only coord and ID, but that did
> not show something either.
> >
> > As I cannot share the connection info, I'm happy to share my screen or
> so to show this.
> >
> > SELECT version();
> > version()|
> > -+
> > 8.0.34-26|
> >
> > but is an upgraded db, not sure where it came from
> >
> > Regards,
> >
> > Richard Duivenvoorde
> >
> >
> > On 1/12/24 15:06, Richard Duivenvoorde via QGIS-Developer wrote:
> > > Hi Devs,
> > >
> > > I was contacted by a company who after upgrading their db and QGIS did
> NOT see the points anymore.
> > >
> > > Note that 'all worked' when they used QGIS 3.10 (and an older mysql db)
> > > After a MySQL database upgrade, QGIS 3.10 was not able to connect
> anymore (apparently TLS issues), so they have to use 3.28 or higher.
> > >
> > > A small export loaded in my local db was OK in QGIS.
> > >
> > > So in a online meeting, sharing their screen I tried:
> > >
> > > - opening the db with ogrinfo: all data is visible (POINT(.))
> showing correct coords and attributes
> > > - loading the table (25000 records) in QGIS: data: EPSG:31370 project
> EPSG:31370 :
> > >  - attribute table shows all records
> > >  - mapcanvas empty!
> > >  - able to 'zoom to' records (Belgium), but NO points
> visible/selectable
> > > - creating a tiny table with only id and geom column of 3 records:
> mapcanvas emtpy
> > > - export the loaded (but invisible) layer to a geopackage: points AND
> attributes VISIBLE!
> > > - loading the data in dbeaver: all data is shown in the spatial tab
> > >
> > > There was an encoding issue when exporting to gpkg, but we tried to
> create a smaller table (very few columns): nothing.
> > >
> > > Anybody familiar with QGIS and Mysql has an idea what this not showing
> of any point/geom could be?
> > >
> > > Any hint appreciated, I plan to try to get a connection to the db
> myself, but hoping I just miss something obvious...
> > >
> > > 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
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   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 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] Running unit tests without "make install"

[Nyall Dawson via QGIS-Developer]

On Tue, 16 Jan 2024, 7:28 am Thomas Larsen Wessel, 
wrote:

> Thanks for having a look at it :) I ran a complete test and saved the test
> output to this gist. Is that what you were looking for? Please tell me what
> other info you need.
>
> https://gist.github.com/velle/b195bee9a5d63e95ea7aa600b7833be1
>

Try with "ctest -v" to get the full log of the tests

Nyall



>
> On Mon, Jan 15, 2024 at 7:54 AM Nyall Dawson 
> wrote:
>
>>
>>
>> On Mon, 15 Jan 2024, 3:42 pm Thomas Larsen Wessel, 
>> wrote:
>>
>>> When you guys run these tests locally, do they all pass?
>>>
>>> After some fiddling I have removed some errors, caused by incorrect
>>> build setup. But I still have  19 failing tests.
>>>
>>> 2 - checkGitStatus (Failed)
>>> 22 - ProcessingGrass7AlgorithmsRasterTestPt2 (Failed)
>>> 24 - ProcessingOtbAlgorithmsTest (Failed)
>>> 46 - test_core_compositionconverter (Failed)
>>> 108 - test_core_layoutpicture (Failed)
>>> 177 - test_core_settingsentry (Failed)
>>> 280 - test_gui_filedownloader (Subprocess aborted)
>>> 288 - test_gui_featurelistcombobox (Subprocess aborted)
>>> 298 - test_gui_queryresultwidget (Subprocess aborted)
>>> 302 - test_3d_3drendering (Failed)
>>> 309 - test_3d_mesh3drendering (Failed)
>>> 332 - test_provider_wcsprovider (Failed)
>>> 413 - PyQgsAnnotation (Failed)
>>> 489 - PyQgsExternalStorageWebDav (Failed)
>>> 490 - PyQgsExternalStorageAwsS3 (Failed)
>>> 600 - PyQgsMapCanvas (Failed)
>>> 601 - PyQgsMapCanvasAnnotationItem (Failed)
>>> 672 - PyQgsProcessExecutablePt1 (Failed)
>>> 673 - PyQgsProcessExecutablePt2 (Failed)
>>>
>>> I think I understand checkGitStatus and can safely ignore that one. But
>>> what about the rest? Is it "normal" that so many tests fail when running
>>> tests locally?
>>>
>>
>> That's more than I'd expect to fail on 22.04 -- at least, the main qgis
>> ci workflow uses 22.04 and most of these are passing !
>>
>> (See https://github.com/qgis/QGIS/blob/master/.ci/test_flaky.txt and
>> https://github.com/qgis/QGIS/blob/master/.ci/test_blocklist_qt5.txt for
>> lists of the tests skipped on the GitHub workflows)
>>
>>
>>> Would any of these tests give a different result if I first ran "make
>>> install"?
>>>
>>
>> Unlikely.
>>
>> I'd be interested to see a full log of the failures if you want to upload
>> it to a gist/Pastebin/ somewhere.
>>
>> Nyall
>>
>>
>>> Im running Ubuntu 22.04, and installed all dependencies via APT as
>>> advised in the qgis build docs. I built QGIS release-3_34 from source and
>>> am now trying to test that build, by running "ctest".
>>>
>>>
>>> On Mon, Jan 1, 2024 at 12:34 AM Thomas Larsen Wessel 
>>> wrote:
>>>
 Thanks both of you :) And happy new year.

 On Sun, Dec 31, 2023 at 11:38 PM Nyall Dawson 
 wrote:

>
>
> On Mon, 1 Jan 2024, 6:36 am Thomas Larsen Wessel via QGIS-Developer, <
> qgis-developer@lists.osgeo.org> wrote:
>
>> The docs (
>> https://docs.qgis.org/3.28/en/docs/developers_guide/unittesting.html#run-your-tests)
>> specify: *make && make install && make test*.
>>
>> I would rather not run make install, since I have another instance of
>> QGIS installed via APT, and I worry running make install will somehow 
>> make
>> a mess and leave me without a working instance.
>>
>> But is it really necessary to run make install before make run? In
>> fact it seems more natural to me to test before installing!
>>
>
> Try running "ctest" from your build directory. There's no need to
> install if doing it this way. (It's how I do all of my development)
>
> Nyall
>
>>
>> Sincerely
>> ___
>> 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] RV: PyQGIS QgsLayoutExporter gives error "QPen::setWidthF: Setting a pen width that is out of range"

[Nyall Dawson via QGIS-Developer]

On Sun, 14 Jan 2024, 6:35 pm Robert via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> # Generate atlas
>
> # Es una QgsLayoutAtlas
>
> myAtlas.beginRender()
>
> myAtlas.next()
>
> for i in range(0, myAtlas.count()):
>
>
>
> exporter = QgsLayoutExporter(myAtlas.layout())
>
> file_name=os.path.join(dir_destiny,'Individuals')+'/'+myAtlas.currentFilename()+".pdf"
>
>
>
> pdf_settings=QgsLayoutExporter.PdfExportSettings()
>
> pdf_settings.forceVectorOutput=False
>
> pdf_settings.exportMetadata = False
>
> pdf_settings.appendGeoreference = False
>
>
>
> #pdf_settings.textRenderFormat = 
> QgsRenderContext.TextFormatAlwaysOutlines  # For "Always Export Text as Paths"
>
> pdf_settings.textRenderFormat = QgsRenderContext.TextFormatAlwaysText # 
> For "Always Export Text as Text Objects"
>
>
>
> pdf_settings.rasterizeWholeImage = True # For "Disable tiled raster layer 
> exports" Hace que ocupe menos si es TRUE
>
> pdf_settings.simplifyGeometries = False
>
>
>
> exporter.exportToPdf(file_name,pdf_settings)
>
>
>
> Thank you In advance for your attention and help.
>

Have you stripped code out of this loop? Eg I can't see any call to
atlas.next() within the loop.

In any case what you have looks generally ok. You'd need to share more of
your code or project to diagnose further.

Nyall

>
>
> Kind regards,
>
>
>
> Robert Benet
>
>
> ___
> 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] Running unit tests without "make install"

[Nyall Dawson via QGIS-Developer]

On Mon, 15 Jan 2024, 3:42 pm Thomas Larsen Wessel, 
wrote:

> When you guys run these tests locally, do they all pass?
>
> After some fiddling I have removed some errors, caused by incorrect build
> setup. But I still have  19 failing tests.
>
> 2 - checkGitStatus (Failed)
> 22 - ProcessingGrass7AlgorithmsRasterTestPt2 (Failed)
> 24 - ProcessingOtbAlgorithmsTest (Failed)
> 46 - test_core_compositionconverter (Failed)
> 108 - test_core_layoutpicture (Failed)
> 177 - test_core_settingsentry (Failed)
> 280 - test_gui_filedownloader (Subprocess aborted)
> 288 - test_gui_featurelistcombobox (Subprocess aborted)
> 298 - test_gui_queryresultwidget (Subprocess aborted)
> 302 - test_3d_3drendering (Failed)
> 309 - test_3d_mesh3drendering (Failed)
> 332 - test_provider_wcsprovider (Failed)
> 413 - PyQgsAnnotation (Failed)
> 489 - PyQgsExternalStorageWebDav (Failed)
> 490 - PyQgsExternalStorageAwsS3 (Failed)
> 600 - PyQgsMapCanvas (Failed)
> 601 - PyQgsMapCanvasAnnotationItem (Failed)
> 672 - PyQgsProcessExecutablePt1 (Failed)
> 673 - PyQgsProcessExecutablePt2 (Failed)
>
> I think I understand checkGitStatus and can safely ignore that one. But
> what about the rest? Is it "normal" that so many tests fail when running
> tests locally?
>

That's more than I'd expect to fail on 22.04 -- at least, the main qgis ci
workflow uses 22.04 and most of these are passing !

(See https://github.com/qgis/QGIS/blob/master/.ci/test_flaky.txt and
https://github.com/qgis/QGIS/blob/master/.ci/test_blocklist_qt5.txt for
lists of the tests skipped on the GitHub workflows)


> Would any of these tests give a different result if I first ran "make
> install"?
>

Unlikely.

I'd be interested to see a full log of the failures if you want to upload
it to a gist/Pastebin/ somewhere.

Nyall


> Im running Ubuntu 22.04, and installed all dependencies via APT as advised
> in the qgis build docs. I built QGIS release-3_34 from source and am now
> trying to test that build, by running "ctest".
>
>
> On Mon, Jan 1, 2024 at 12:34 AM Thomas Larsen Wessel 
> wrote:
>
>> Thanks both of you :) And happy new year.
>>
>> On Sun, Dec 31, 2023 at 11:38 PM Nyall Dawson 
>> wrote:
>>
>>>
>>>
>>> On Mon, 1 Jan 2024, 6:36 am Thomas Larsen Wessel via QGIS-Developer, <
>>> qgis-developer@lists.osgeo.org> wrote:
>>>
 The docs (
 https://docs.qgis.org/3.28/en/docs/developers_guide/unittesting.html#run-your-tests)
 specify: *make && make install && make test*.

 I would rather not run make install, since I have another instance of
 QGIS installed via APT, and I worry running make install will somehow make
 a mess and leave me without a working instance.

 But is it really necessary to run make install before make run? In fact
 it seems more natural to me to test before installing!

>>>
>>> Try running "ctest" from your build directory. There's no need to
>>> install if doing it this way. (It's how I do all of my development)
>>>
>>> Nyall
>>>

 Sincerely
 ___
 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] [Qgis-psc] QGIS grant report: Improve test result handling on QGIS CI

[Nyall Dawson via QGIS-Developer]

On Thu, 4 Jan 2024, 5:23 am Sandro Santilli,  wrote:

> On Mon, Nov 27, 2023 at 05:09:07PM +1000, Nyall Dawson via QGIS-PSC wrote:
> > On Mon, 27 Nov 2023, 4:56 pm Alessandro Pasotti, 
> wrote:
> >
> > > https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755
> > > comment the instructions say:
> > >
> > > "The full test report (included comparison of rendered vs expected
> > > images) can be found under the 'Checks' tab - 'QGIS tests',
> > > 'Artifacts' section as test-results-5."
> > >
> > > But I couldn't find any test-results-5 in the artifacts section
> >
> > That's caused by a limitation in GitHub API.
>
> Would it be possible for that comment to contain instruction about how
> to run that test locally ? Helping developers running failing tests
> locally would reduce load on shared infrastructure.
>

Good idea, but unfortunately non trivial to execute ☹️

Obstacles are:

- We need the ctest name for the test so that associated ctest -R
"^testname\$" command can be determined to run just one test file.

- We don't have access to the ctest name for the current test being
executed during the test.  So we'd have to **hardcode** these into each
test individually. (There's unfortunately no fixed pattern used to specify
the ctest test name from the actual test source file name, so we can't use
qtest methods or macros which give us the source file name here)

- If we want to generate a command which will run just ONE function from
the test, then we hit against
https://gitlab.kitware.com/cmake/cmake/issues/20470 . (This could possibly
be worked around using a variation on https://stackoverflow.com/a/77084304)

So not impossible to do, but also a considerable amount of work. If someone
else takes this on I'm happy to review. 👍

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] Running unit tests without "make install"

[Nyall Dawson via QGIS-Developer]

On Mon, 1 Jan 2024, 6:36 am Thomas Larsen Wessel via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> The docs (
> https://docs.qgis.org/3.28/en/docs/developers_guide/unittesting.html#run-your-tests)
> specify: *make && make install && make test*.
>
> I would rather not run make install, since I have another instance of QGIS
> installed via APT, and I worry running make install will somehow make a
> mess and leave me without a working instance.
>
> But is it really necessary to run make install before make run? In fact it
> seems more natural to me to test before installing!
>

Try running "ctest" from your build directory. There's no need to install
if doing it this way. (It's how I do all of my development)

Nyall

>
> Sincerely
> ___
> 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] [Qgis-psc] QGIS grant report: Improve test result handling on QGIS CI

[Nyall Dawson via QGIS-Developer]

On Mon, 27 Nov 2023 at 17:21, Laurențiu Nicola  wrote:

> On Mon, Nov 27, 2023, at 09:09, Nyall Dawson via QGIS-Developer wrote:
>
> That's caused by a limitation in GitHub API. We can't retrieve the
> workflow run id in an action, so that link will always just point to the
> most recent workflow run for the PR.
>
>
> Hi Nyall,
>
> I'm not sure if that's the one you're missing, and you might be aware of
> it, but there's a run_id field in the
> https://docs.github.com/en/actions/learn-github-actions/contexts#github-context
> .
>

Thanks! This got me thinking about another approach to take... and we've
finally got there:
https://github.com/qgis/QGIS/pull/55423#issuecomment-1829008969

Now there's a direct link to the test report zip file in the comment!

Nyall


>
> Laurentiu
>
>
___
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] QGIS grant report: Improve test result handling on QGIS CI

[Nyall Dawson via QGIS-Developer]

On Mon, 27 Nov 2023, 4:56 pm Alessandro Pasotti,  wrote:

> Hi Nyall,
>
> good news, thank you for this improvement!
>
> Just a quick question, in the linked PR:
> https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755
> comment the instructions say:
>
> "The full test report (included comparison of rendered vs expected
> images) can be found under the 'Checks' tab - 'QGIS tests',
> 'Artifacts' section as test-results-5."
>
> But I couldn't find any test-results-5 in the artifacts section, there are
> only:
>
> Artifacts
> build-22.04-qt5.tgz
> build-38-qt6.tgz
>

That's caused by a limitation in GitHub API. We can't retrieve the workflow
run id in an action, so that link will always just point to the most recent
workflow run for the PR.

And in this case I reverted the change causing a test failure, so the most
recent workflow doesn't have the failure report.

Hope that makes sense!

Nyall

>
> Cheers.
>
>
> On Mon, Nov 27, 2023 at 5:29 AM Nyall Dawson via QGIS-PSC
>  wrote:
> >
> > Hi PSC,
> >
> > I'm happy to announce that this grant is now complete!
> >
> > While the original proposal was explicitly stated to be a research
> project with no guarantees of success, the end result is predominantly a
> success (with some limitations!)
> >
> > You can see the new failure handling in action in this PR:
> https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755
> >
> > What we have now is that any tests which fail a rendering comparison
> will write a descriptive comment to the PR, as shown in the above link. The
> comment details which render tests failed, where they are in the code, and
> includes some helpful pointers to downloading the full test report and the
> QGIS developer documentation.
> >
> > Originally, I hoped to link directly to the full test report or include
> it as an attachment to the comment. Unfortunately this is NOT possible
> given the current Github API. There's a bunch of notes I've added to the
> initial comment in https://github.com/qgis/QGIS/pull/54906 which link to
> the limitations / feature requests on Github's side, so we can monitor the
> situation and further improve the reports if/when Github add this
> functionality.
> >
> > As well as the above described improvements on the CI side, I've also
> implemented lots of improvements in running the tests locally and how the
> render test reports are generated and presented to developers!
> >
> > Thanks for making this possible!
> >
> > Nyall
> >
> >
> >
> >
> >
> > ___
> > QGIS-PSC mailing list
> > qgis-...@lists.osgeo.org
> > https://lists.osgeo.org/mailman/listinfo/qgis-psc
>
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   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] QGIS grant report: Improve test result handling on QGIS CI

[Nyall Dawson via QGIS-Developer]

Hi PSC,

I'm happy to announce that this grant is now complete!

While the original proposal was explicitly stated to be a research project
with no guarantees of success, the end result is predominantly a success
(with some limitations!)

You can see the new failure handling in action in this PR:
https://github.com/qgis/QGIS/pull/55417#issuecomment-1826995755

What we have now is that any tests which fail a rendering comparison will
write a descriptive comment to the PR, as shown in the above link. The
comment details which render tests failed, where they are in the code, and
includes some helpful pointers to downloading the full test report and the
QGIS developer documentation.

Originally, I hoped to link directly to the full test report or include it
as an attachment to the comment. Unfortunately this is NOT possible given
the current Github API. There's a bunch of notes I've added to the initial
comment in https://github.com/qgis/QGIS/pull/54906 which link to the
limitations / feature requests on Github's side, so we can monitor the
situation and further improve the reports if/when Github add this
functionality.

As well as the above described improvements on the CI side, I've also
implemented lots of improvements in running the tests locally and how the
render test reports are generated and presented to developers!

Thanks for making this possible!

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 Full Stack Web Developer Report

[Nyall Dawson via QGIS-Developer]

On Mon, 27 Nov 2023 at 00:19, Tim Sutton via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> @Matthias Kuhn and @Julien Moura I fixed the permissions, the board for
Lova is public now. Please feel free to add items to the backlog and mark
them as priority as needed.  I also asked Lova to try to work through all
the old issues and fix / close them as appropriate so we can try to get the
number of tickets down to a small number.

Tim/Lova, thanks for your outstanding efforts and commitment here!

It's really exciting to see all the love and attention that the web and
plugin infrastructure is getting as a result! 😍

Nyall

>
> Regards
>
> Tim
>
> On Sat, Nov 25, 2023 at 8:37 AM Matthias Kuhn  wrote:
>>
>> Hi,
>>
>> Thank you very much Lova for working on this application, it's a very
important piece in the QGIS ecosystem!
>>
>> For the current discussion, I would also suggest making the license
recommended for now and only start enforcing it on a schedule. And I was
wondering if a license field in the metadata.txt would be even better (cmp.
https://python-poetry.org/docs/pyproject/#license), that would be easier to
show on the plugin page?
>>
>> Is there any way to help prioritizing the issues? I have some wishes
that I would love to see land on the backlog
>>
>> Kind regards and thanks again for all the good work on this !
>> Matthias
>>
>> On Fri, Nov 24, 2023 at 11:49 AM Julien Moura via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>>>
>>> Dear Tim,
>>>
>>> Thanks for taking in account my thoughts and make the discussion
possible.
>>>
>>> Regarding the second about change management, I totally agree and feel
really thankful that you make those changes. I can imagine the work it
represents for your teams maintaining a project like this one. So thank you
again.
>>>
>>> Regarding your proposal about the license requirements, why not
starting apply the change management to this? It's a breaking change, even
for new plugins, right? So, it should be lowered to a non blocking warning,
documented in PyQGIS cookbook and then deployed as a blocking error in a
known time windows. This way, in the meanwhile, the plugins ecosystem can
adapt to new rules (new versions for tools like minimal plugin,
qgis-plugin-ci, plugin builder...) and make this change more acceptable and
frictionless.
>>>
>>> Moreover, the rationale behind the required license file into the
plugin archive is still not solved.
>>>
>>> If you want, I can make a PR to change the warning but I'm pretty sure
that's not the question here.
>>>
>>> https://github.com/orgs/qgis/projects/6
>>>
>>> Just to let you know this hyperlink leads to a 404 (probably a Github
rights access setting somewhere).
>>>
>>> Regards
>>>
>>> On 24/11/2023 10:50, Tim Sutton wrote:
>>>
>>> Dear Julien
>>>
>>> Thank you so much for your engagement and suggestions. Fully agreed
that breaking changes should be well communicated first. So splitting the
discussion in two:
>>>
>>>
>>> 1) License requirements: for now I have chatted with Lova and we
propose:
>>>
>>> a) Change the logic such that a license is required for newly
registered plugins
>>> b) When updates are made to existing plugins that do not include a
license, the uploader will be shown a warning indicating that in future the
license will  be mandatory
>>>
>>> This is already implemented in
https://github.com/qgis/QGIS-Django/pull/311 and I propose we deploy this
today / ASAP to address the previously raised issues.
>>>
>>> 2) Change management:
>>>
>>> Yes I think we can introduce more rigour in the process.
>>>
>>> * breaking changes: discuss with the community first, implement, deploy
in a known time window
>>> * non-breaking changes: for simple bug fixes, just fix, test and deploy
as needed
>>> * non-breaking changes: for features etc. these will be managed on the
project board here, anyone who wants to be engaged in the process can see
the planned upcomming work and interact with Lova via the ticket queue.
https://github.com/orgs/qgis/projects/6
>>> * requests to improvements: please file tickets here
https://github.com/qgis/QGIS-Django/issues
>>>
>>> Regarding a staging site, currently we do not run a staging
environment, developers have local test environments and I am on the fence
as to whether there is a lot of value in us maintaining a long running
staging site.
>>>
>>> Regards
>>>
>>> Tim
>>>
>>>
>>>
>>>
>>> On Fri, Nov 24, 2023 at 8:08 AM Lova Andriarimalala via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

 Dear Julien,



 That’s well noted. Thank you.

 I will add a detailed description in each PR in the future.

 Regarding the issue of LICENSE file requirements, I totally agree with
you. I will also ask Tim if he has suggestions about it.



 Best regards,

 Lova



 —



 Lova Andriarimalala

 QGIS Full Stack Developer

 Visit http://kartoza.com to find out about o

Re: [QGIS-Developer] Embedded styling in some datatypes

[Nyall Dawson via QGIS-Developer]

On Fri, 24 Nov 2023 at 17:28, Régis Haubourg via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> Hi Bo,
> Regarding MapInfo, I know the french ministry of environment has tried
something like this years ago.
> It was an attempt to handle the transition period between M and Q.
>
> But honestly the style specifications of each proprietary format are
really hard to interoperate. This leads to partially compatible styles, and
data loss.
>
> SLD was a promise to have a common standard but I think all the
developers that tried to implement conversion utilities have been having
hard days. Maybe except for Slyr by Nyall.
> Data can be shared across systems. But styles can be shared with very
limited support and this somewhat negates the work of talented
cartographers.

FWIW, symbology can be converted from ArcMap -> QGIS almost completely
losslessly. And from ArcGIS Pro -> QGIS at ≊95% losslessly.  And then from
QGIS -> ArcGIS Pro at ≲ 50%. We've well overtaken Arc in what's possible in
map symbology in recent years. 🥳

Nyall




>
>
>
> Le jeu. 23 nov. 2023, 11:51, Bo Victor Thomsen via QGIS-Developer <
qgis-developer@lists.osgeo.org> a écrit :
>>
>> Hi list -
>>
>> I'm wondering about how to use embedded styling in certain types of file
>> formats (like MapInfo Tab). I know its possible to read the embedded
>> styling from a Tab fil and then convert it to a styling object in QGIS.
>>
>> However, what about the other direction ? Take a specific QGIS style
>> from the layer styling of a tab file, and and write the specific style
>> into the feature, so it will be present if you later open the tab file
>> in (gasp!) MapIno ?
>>
>> The use case would be organisations that have a mixed environment of
>> QGIS and MapInfo installations. It would allow QGIS users to create and
>> update object in a .tab file and save the file. Later this file - if
>> opened in MapInfo (or QGIS) - would be shown with the correct embedded
>> styling.
>>
>> --
>> Med venlig hilsen / Best regards
>>
>> Bo Victor Thomsen
>>
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] Embedded styling in some datatypes

[Nyall Dawson via QGIS-Developer]

On Thu, 23 Nov 2023 at 20:51, Bo Victor Thomsen via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> Hi list -
>
> I'm wondering about how to use embedded styling in certain types of file
> formats (like MapInfo Tab). I know its possible to read the embedded
> styling from a Tab fil and then convert it to a styling object in QGIS.
>
> However, what about the other direction ? Take a specific QGIS style
> from the layer styling of a tab file, and and write the specific style
> into the feature, so it will be present if you later open the tab file
> in (gasp!) MapIno ?

There's an option in the right-click, Export - Save Features As dialog for
"Symbology Export". This only shows up for some formats (depending on GDAL
library support for that format), of which Mapinfo TAB is one. If you set
this to anything other than "No Symbology" then ** IN SOME CASES
** the QGIS symbology will be written as the embedded symbols for
the features.

The big disclaimer is that the GDAL api for embedding styles, AND the
underlying format support is very limited compared with QGIS symbology
options. Eg it'll work for embedding colored line symbols, but won't for
shapeburst gradient fill polygons with data defined overrides 🤣!

There's likely many ways we could improve this at both the QGIS and GDAL
levels to better handle the full range of symbology options possible in TAB
files, and adding more graceful fallbacks from QGIS symbology to the
limited symbology options possible in GDAL/TAB.

Nyall



>
> The use case would be organisations that have a mixed environment of
> QGIS and MapInfo installations. It would allow QGIS users to create and
> update object in a .tab file and save the file. Later this file - if
> opened in MapInfo (or QGIS) - would be shown with the correct embedded
> styling.
>
> --
> Med venlig hilsen / Best regards
>
> Bo Victor Thomsen
>
> ___
> 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] QEP: Authentication system updates

[Nyall Dawson via QGIS-Developer]

Hi lists,

I've created a new QGIS enhancement proposal at
https://github.com/qgis/QGIS-Enhancement-Proposals/issues/278
concerning changes to the inbuilt authentication system / secure storage
support in QGIS.

By its nature, the authentication framework needs to be secure and any
changes to the authentication logic need careful consideration.

Comments and discussion on the github ticket linked above are encouraged!

Kind regards,
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] Future of OTB provider plugin?

[Nyall Dawson via QGIS-Developer]

On Mon, 13 Nov 2023, 6:28 pm Julien Cabieces via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

>
> Hi,
>
> +1 for me too, I think it would ease development of the plugin and would
> lower the pain of managing compatibility between QGIS and OTB.
>
> I opened an issue on their GitLab platform to raise awareness of this
> proposal https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2365


Thanks Julien!

Would you be interested in potentially adopting the community plugin?

Nyall



>
> Regards,
> Julien
>
>
>
> > Hi
> >
> > +1 from me too.
> >
> > Regards
> >
> > Tim
> >
> > On Sun, Nov 12, 2023 at 9:46 PM Jürgen E. Fischer via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
> >
> >  Hi Nyall,
> >
> >  On Mon, 13. Nov 2023 at 07:38:49 +1000, Nyall Dawson via QGIS-Developer
> wrote:
> >  > So... what does everyone else think? Can we safely demote OTB to a 3rd
> >  > party plugin and remove it for QGIS 3.36?
> >
> >  +1
> >
> >  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
> https://www.norbit.de
> >  QGIS release manager (PSC)  Germany IRC: jef on
> Libera|OFTC
> >  ___
> >  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
>
>
> --
>
> Julien Cabieces
> Senior Developer at Oslandia
> julien.cabie...@oslandia.com
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Future of OTB provider plugin?

[Nyall Dawson via QGIS-Developer]

Hi list,

I'd like to kick start some discussions about the future of the official
OTB Processing Provider plugin which comes pre-installed with QGIS.

As you may or may not be aware of, the Processing maintainers have been on
a multi-year quest to slim down the core set of out-of-the-box providers.
The biggest consequences of these have been the demotion of the Processing
R Providers and SAGA providers to 3rd party, community maintained plugins.

The main motivations behind this are:

- Making sure that all the out of the box tools "just work" consistently
across different platforms, without requiring users to install additional
software.
- Easing the maintenance burden on the core QGIS team -- by moving these
plugins to community maintained repositories, we lower the barrier of entry
for contributors to these plugins.
- Avoiding issues with "tight coupling" of 3rd party tools to QGIS
versions. This was especially the case with the SAGA provider, where it
proved impossible to keep a stable plugin which worked consistently across
the range of SAGA versions installable on different platforms. (The 3rd
party SAGA NG plugin avoids this by ALWAYS targeting the most recent SAGA
version, and leaving it as the user's responsibility for installing this
version. We didn't have the same flexibility when the SAGA provider was a
core part of QGIS).

I'd like to now focus on the out-of-the-box OTB Processing provider, and
personally I would like to see this one demoted to a community maintained
plugin.

My reasons are:
1. The provider has not seen development efforts outside of "keep this
running only" by the usual QGIS committers. I would hope to see the same
results as we saw with the R and SAGA plugins where moving to community
maintained plugins increases the number of outside contributions.
2. OTB requires a separate installation outside of QGIS, and isn't easily
available on many supported QGIS platforms (eg there's no Fedora package).
 3. The OTB installer does some weird thing in the QGIS ci environment,
which make me nervous:

2023-11-12T12:54:48.9064680Z #26 18.57 warning: working around a Linux
kernel bug by creating a hole of 20480 bytes in
‘./lib/libQt5Core.so.5.10.1’

So... what does everyone else think? Can we safely demote OTB to a 3rd
party plugin and remove it for QGIS 3.36?

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] Changelog descriptions for Scenes

[Nyall Dawson via QGIS-Developer]

On Thu, 2 Nov 2023 at 19:01, Tim Sutton via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:

> Hi all
>
> Martin / Nyall - I noticed we don't have anything in the 3.34 changelog (
> https://changelog.qgis.org/en/qgis/version/3.34) for the new 3D scenes,
> adding Cesium / Google 3d tiles. I think most users won't even realise this
> cool new functionality is there. Could you share some content for us to add
> to the changelog (and for Selma to add to the user manual)?
>

Hi Tim!

I've submitted a PR adding this at
https://github.com/qgis/QGIS-Website/pull/1197 .

I can't work out how to embed a video for the item though... it needs to
have the video at https://youtu.be/lvl8zVZ8glY attached. Any ideas?

Nyall



>
> Thanks!
>
> Tim
>
> --
>
> --
>
> Tim Sutton
> Kartoza Co-Founder
> 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
>
> ---
> ___
> 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] Removing __author__ , __date__, __copyright__ from python files?

[Nyall Dawson via QGIS-Developer]

Hey list,

I'd like to propose that we remove all the __author__ , __date__ and
__copyright__ strings from the python files in our repository.

My thinking:

- This isn't an official Python style standard or universally recommended
approach. It *is* used elsewhere, but there's an equally large group which
consider it just unnecessary noise.
- It's misleading, and presents the incorrect impression that a single
person is responsible for the code in that file. That's 100% NOT the case
with QGIS.
- It's all redundant. This information is available in a MUCH more accurate
form via git history.

Are there any objections to removing this?

(For completeness: In a follow up proposal I'm going to suggest removing
ALL the "Date: / Copyright: / Email: " strings from our file headers, for
the same reasons).

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] Open plugin automatically when file is dragged onto QGIS

[Nyall Dawson via QGIS-Developer]

On Mon, 6 Nov 2023, 6:32 am David Signer via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> You can use an eventfilter. You can find an example here
> https://github.com/opengisch/QgisModelBaker/blob/master/QgisModelBaker/qgismodelbaker.py#L507C7-L552
>

A better approach would be a QgsCustomDropHandler. See

https://api.qgis.org/api/3.28/classQgsCustomDropHandler.html

Nyall


>
> However, it may be appropriate to have a setting for this. In the plugin
> mentioned above, the user is asked if they want to open this type of file
> always with this plugin in the future.
>
> Cheers
> Dave
>
> On Sun, Nov 5, 2023 at 1:54 AM Pankajeshwara Sharma via QGIS-Developer <
> qgis-developer@lists.osgeo.org> wrote:
>
>> Hello all,
>>
>> I would like a feature within QGIS so that when files with ".xyz"
>> extension are dragged onto the application, would make my plugin to open
>> automatically.
>> This can prevent the user from having to go to the File menu and open the
>> file.
>>
>> This is similar to when shapefiles are dragged onto QGIS, and the
>> shapefiles are automatically loaded and displayed in QGIS.
>> Except, dragging a file with a ".xyz" extension should result in my
>> plugin (a dialog box from then plugin) to open.
>>
>> Is there a setting I can configure?
>>
>> Yours sincerely,
>> Pankaj Sharma
>> Research Fellow
>> University of Auckland
>> pankaj.sha...@auckland.ac.nz
>> ___
>> QGIS-Developer mailing list
>> QGIS-Developer@lists.osgeo.org
>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] QGIS repository management

[Nyall Dawson via QGIS-Developer]

>
> IMHO, the main issue here is that the CI is too often broken for no
> reasons related to the PR content. And most of the time recently, it's
> because of one of the mingw jobs.

I suggest we move this conversation into more practical areas and
focus instead on the actual CI issues.

In my experience there's a couple of main issues here:

1. The mingw build fails often with the error:

cd /__w/QGIS/QGIS/build_mingw64/resources && /usr/bin/cmake -E copy
/__w/QGIS/QGIS/resources/srs6.db
/__w/QGIS/QGIS/build_mingw64/resources/srs.db
make[2]: write error: stdout

It always succeeds if you restart the job though. I don't know what's
causing this... a disk space issue? (but then why would it succeed on
the following attempt?)

2. The msys2 build can take HOURS (5+ in some cases). The qt 5/ qt6
builds also see occasional extremely slow builds.

I think the root cause of this is that we've exhausted all the
available space allowed for caching objects on github. All the builds
are trying to cache things to speed up the workflows, but the
different caches are randomly getting deleted because together they've
well exceeded the total allowed size. The solutions I could see here
are:

- approaching github to ask nicely for more space
- dropping one or more workflows. Maybe we could combine the msys2 and
mingw workflow into one to cut out one workflow. But that's blocked
because the msys2 workflow currently has a lot of things disabled
(including python), so it's currently not a suitable replacement for
the mingw builds which give end users an easy way to test PRs on
windows.

3. Random test failures. Main culprits are:
- ept provider test (but I **think** I've fixed this with
improvements/fixes made over the 3.34 bug fixing period). At least, I
don't recall seeing this in the last week, when it used to be a daily
random fail.
- raster file writer test: randomly fails for an unknown reason. The
test passes valgrind/asan fine, so I suspect the random failures are
caused by some interplay with other tests modifying data in the test
data folder. More work is needed.
- raster analysis utils test: same as above.
- network access manager test: depends on the badssl external website,
which goes down occasionally. We could potentially run this site
ourselves as part of the CI setup, but that's trading the dependence
on an external service for added CI maintenance burden on ourselves.

4. Docker/ubuntu repository fails. This happens occasionally -- the
external repos will have transient connectivity issues. Not much we
can do here except manually re-running the jobs.

Is there anything I've missed?

Nyall









>
> Like proposed by Matthias, I would be very much in favor in modifying
> our CI jobs to rely on non-rolling release distribution.
>
> Regards,
> Julien
>
>
> > In my experience, the peer reviews have proven to be an effective tool to 
> > improve the code quality.
> > I think it can be explained with a four eyes principle. The first two eyes 
> > are involved in writing the code, the second pair of eyes that validates
> > needs to be a trusted pair.
> > For a code base of the maturity of QGIS, this seems to me to be justified 
> > and reasonable.
> >
> > As for who can do a review, a potential conflict of interest has been 
> > raised. This arises most noticeable within a single company, but can also
> > very well be the case whenever a collaboration occurs between multiple 
> > individuals or if a well-connected client is involved. In my experience, in
> > most cases people will first ask the person that they trust to be most 
> > qualified to review a specific area of the code, regardless the organisation
> > they work for. In some cases, this may be your colleagues. What I and 
> > others have done in the past in such cases, is to leave an additional review
> > window of a couple of days before merging to give everyone the opportunity 
> > to jump in if they wanted to, just to be sure to play it fair. In my
> > experience, this worked quite nicely, but I am also open to other 
> > approaches.
> >
> > As for failing tests, I think one possibly low hanging fruit would be to 
> > switch all CI workflows to be based on non-rolling distributions. And we
> > could potentially also be a bit more strict with disabling flaky tests or 
> > making them optional.
> >
> > Best wishes
> > Matthias
> >
> > On Tue, Oct 17, 2023 at 9:47 AM Sandro Santilli via QGIS-Developer 
> >  wrote:
> >
> >  On Tue, Oct 17, 2023 at 03:08:34PM +1300, Nyall Dawson via QGIS-Developer 
> > wrote:
> >  > On Tue, 17 Oct 2023 at 03:41, Sandro Santilli  wrote:
> >  > >
> >  > > On Mon, Oct 16, 2023 at 09:59:35

Re: [QGIS-Developer] QGIS repository management

[Nyall Dawson via QGIS-Developer]

On Tue, 17 Oct 2023 at 03:41, Sandro Santilli  wrote:
>
> On Mon, Oct 16, 2023 at 09:59:35AM +1300, Nyall Dawson via QGIS-Developer 
> wrote:
>
> > If you flip the situation, you'll see that yes, you do have trust!
> >
> > - a complete stranger CANNOT approve their own changes
> > - a complete stranger CANNOT approve other stranger's changes
> > - a complete stranger CANNOT approve an approved member's changes
> >
> > vs
> >
> > - an approved member CANNOT approve their own changes
> > - an approved member CAN approve a complete stranger's changes
> > - an approved member CAN approve a another approved member's changes
>
> That's partial trust. I'm trusted to be able to judge someone else's
> work but not to judge my own work !

Ok, it's partial trust. What's wrong with that? I wouldn't trust
myself not to make accidental mistakes, or do something inefficient,
or that I'm not duplicating code which is present elsewhere in QGIS. A
second set of eyes over a pull request definitely reduces that risk.
QGIS is MASSIVE, and none of us can keep a complete picture of the
impact of code changes in our heads.

Some real world examples, picked at semi-random (because they are recent):

https://github.com/qgis/QGIS/pull/54941 : Submitted by a core
developer. I reviewed, and it looked good to me. But then a third (!)
set of eyes over the code has revealed a massive potential performance
regression caused by the change (thanks Even!).

https://github.com/qgis/QGIS/pull/54670: Submitted by a very
experienced core developer. Code looks good at first pass, no visible
bugs. But it's introducing a partial duplication of another utility
function implemented elsewhere and exhaustively tested. The review
identified that and as a result we avoided introducing an unnecessary,
non trivial duplication of code.

That's two examples. I'd very conservatively estimate that 1 in 10
approved PRs submitted by core committers have at least one set of
changes suggested and implemented. Let's (pessimistically!) write half
of those off as non-bugs, such as optimisation suggestions or changes
relating to documentation/comments/code style. That's still **AT
BEST** 1 in 20 pull requests submitted by core committers which needed
fixes.

In short: I'm more than OK with only partial trusting everyone. We ALL
make mistakes, so let's stick with the processes we have which reduce
the risk of these mistakes hitting end users..

Nyall


>
> Beside the same-company reviews things, consider I could always ask a
> friend to file PRs for the sole purpose of me being able to merge them
> in (I cannot merge my own...). The policy is flawed to me.
>
> --strk;
___
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 repository management

[Nyall Dawson via QGIS-Developer]

For completeness:

> - an approved member CANNOT approve their own changes
> - an approved member CAN approve a complete stranger's changes
> - an approved member CAN approve a another approved member's changes

A potential issue which has popped up a couple of times is whether
it's acceptable for another staff member from the same organisation to
approve their colleague's PRs. Is this acceptable or not? Is it a
conflict of interest? Does it lean toward lenient reviews and getting
a speedy merge? Or is it good practice because the organisation isn't
placing any burden on others outside of their organization? 🤷 Who
knows! But definitely work discussing if we are writing up formal
policies...

Nyall






>
> I think the misunderstanding is all about naming. If we drop the
> confusing "core committer" label and change it to "approved reviewer",
> then everything becomes clear.
>
> (and then we have a separate "super user" group with repo admin level
> privileges, which should be kept as SMALL as possibly needed to keep
> the repository and CI working, and is unrelated to
> code/trust/experience/etc...)
>
> > Another policy I believe in is that whoever is allowed to apply
> > changes to the repository should take on the responsibility of
> > fixing bugs introduced by those changes.
>
> I'm a hesitant +0 to this. I do think we've all got a good track
> record of fixing our own mistakes within reasonable expectations. I'd
> be concerned that formalising this would put a lot of unreasonable
> expectations on developers (where's the limit? If it's found that I
> broke some esoteric workflow not covered by unit tests 3 years later,
> am I still responsible for fixing that? I'd argue not).
>
> Nyall
> >
> > --strk;
___
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 repository management

[Nyall Dawson via QGIS-Developer]

On Mon, 16 Oct 2023 at 09:44, Sandro Santilli  wrote:
>
> On Mon, Oct 16, 2023 at 08:58:30AM +1300, Nyall Dawson wrote:
> > On Sat, 14 Oct 2023 at 05:43, Sandro Santilli wrote:
> >
> > >   2. Allow those with "write access" to self-approve PRs
> >
> > -1. What's the real motivation here? Why the urgency to get unreviewed code
> > into QGIS?
>
> A recent example of urgency: I broke the pre-commit hook for most
> developers, I could have pushed the fix earlier if I didn't have
> to wait for a review.

That's a fair example, I'll concede that point! I wonder if tagging
the commit with "[skip ci]" would still permit the merge request to be
merged? It's worth a test.

>
> The other motivation is not about urgency but about a conflicting policy:
>
>   - I can be the _only_ reviewer approving a complete stranger's
> proposed change.
>
>   - I can NOT be the _only_ reviewer approving my proposed change.
>
> Is trust given to _me_ as a "reviewer" or not ?
> It is in the first case, it isn't in the second case.

If you flip the situation, you'll see that yes, you do have trust!

- a complete stranger CANNOT approve their own changes
- a complete stranger CANNOT approve other stranger's changes
- a complete stranger CANNOT approve an approved member's changes

vs

- an approved member CANNOT approve their own changes
- an approved member CAN approve a complete stranger's changes
- an approved member CAN approve a another approved member's changes

I think the misunderstanding is all about naming. If we drop the
confusing "core committer" label and change it to "approved reviewer",
then everything becomes clear.

(and then we have a separate "super user" group with repo admin level
privileges, which should be kept as SMALL as possibly needed to keep
the repository and CI working, and is unrelated to
code/trust/experience/etc...)

> Another policy I believe in is that whoever is allowed to apply
> changes to the repository should take on the responsibility of
> fixing bugs introduced by those changes.

I'm a hesitant +0 to this. I do think we've all got a good track
record of fixing our own mistakes within reasonable expectations. I'd
be concerned that formalising this would put a lot of unreasonable
expectations on developers (where's the limit? If it's found that I
broke some esoteric workflow not covered by unit tests 3 years later,
am I still responsible for fixing that? I'd argue not).

Nyall
>
> --strk;
___
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 repository management

[Nyall Dawson via QGIS-Developer]

On Sun, 15 Oct 2023 at 02:54, Sandro Santilli via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> That term "committer", btw, should probably be changed nowadays as
> with git it doesnt' make much sense.

+1. Maybe we should go with "review approver" to reflect exactly what this
privilege means today...

>
> > The QGIS organization has a budget for PR queue management (triage)
> > and a separate entry for reviews (budget is public
> > https://www.qgis.org/en/site/getinvolved/governance/finance/index.html)
> > , in the past this has been working well while I agree that recently
> > PRs have been pending without review for a (too) long time.
>
> The bugfixing spreadsheet has a column to report reviewer names,
> but it looks like I'm the only one filling it at the moment.
> You may notice I've also reported reviews from non-committers
> ( Laurențiu Nicola, in Cc ).

I think everyone is trying to reduce paperwork and that's why that column
is unpopulated 😂

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

[Nyall Dawson via QGIS-Developer]

> A small group of us (3-4 developers including me) have admin access to
> all QGIS repositories and we can bypass any check and merge all PRs
> without approval.

I have this power too -- and I use it on a daily basis to keep the whole CI
setup flowing (ie restarting workflows in other's PRs, merging approved PRs
when an unrelated workflow failure has blocked a merge, etc).

I'd like to point out that it's only used to keep the project humming along
for EVERYONE's benefit -- it's not a conspiracy to create a set of "super
committers" with extra power 😂 .

Nyall


>
> I admit that I have been using these superpowers more and more often
> (IIRC three or four times) in the last year while I have never felt
> the need to use them before, in an ideal world it should not be
> necessary except for the same use cases I have pointed out for the
> direct pushes to master.
>
> The bottom line is that the situation is not perfect and can certainly
> be improved but at the end of the day we are all doing our best to
> keep the process running as smoothly as we can.
>
> Thank you for raising this point, you are absolutely right that it
> should be clearly documented, this has been in our TODO list for a
> long time.
>
> Best regards.
>
>
> On Fri, Oct 13, 2023 at 6:42 PM Sandro Santilli via QGIS-Developer
>  wrote:
> >
> > Hello all,
> > today I was finally able to more clearly see the problem that frustrates
> > me everytime a take part to a new QGIS bugfixing drive, and I would like
> > to share it hoping to find a solution togheter.
> >
> > The main problem:
> >
> >   - Despite having been granted write access to the QGIS repository in
2012
> > [1], I cannot effectively use that power today
> >
> > It's not just me, I think, but I cannot tell for sure because the
configuration
> > of the infrastructure currently in use (github) is not available for me
to see
> > and the governance page on the official QGIS website does not contain
this
> > information [2]. This being blind of course adds up to my frustration.
> >
> > From experience, I know that the reason why I cannot write to the QGIS
> > repository is because "branch protection" is active (for the master
branch
> > at least) and a set of conditions are required to merge a PR, namely:
> >
> >   - All CI tests need to pass.
> >
> >   - Someone else (I don't know from which group of people) needs to
> > approve the proposed change.
> >
> > While I do the above condition being a useful indication for "QGIS
> > core developers" to decide whether to accept or not a change request,
> > I find them representing an obstacle way more often than a service,
> > and in particular:
> >
> > 1. CI is often broken for reasons that are independent from the proposed
> >change.
> >
> > 2. An aberration of the "review" condition is that a change proposed by
a
> >contributor and approved by me can be merged but a change proposed by
> >me and approved by the same contributor can not be merged,
effectively
> >giving me ("core QGIS committer") less power than the power of a
random
> >contributor.
> >
> > The rules described above are not found from the governance page [2]
> > so it isn't easy for me to propose changes because I don't have a clear
> > picture of current rules (like, I believe some people in QGIS can
> > self-approve PRs but dunno how to tell who and why).
> >
> > I would personally welcome (and be able to help taking) the following
actions:
> >
> >   1. Clearly document the roles and rules on the website
> >
> >   2. Allow those with "write access" to self-approve PRs
> >
> >   3. Define rules by which "write access" privileges to the repository
> >  are revoked
> >
> > Thanks for having read this in full, and I hope to hear your position
> > on the matter.  Happy hacking !
> >
> >
> > [1]
https://lists.osgeo.org/pipermail/qgis-developer/2012-October/022715.html
> > [2] https://qgis.org/en/site/getinvolved/governance/governance.html
> >
> > --strk;
> >
> >   Libre GIS consultant/developer
> >   https://strk.kbt.io/services.html
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   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 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 repository management

[Nyall Dawson via QGIS-Developer]

Hi Sandro,

Thanks for raising this discussion. I'll add my knowledge inline below.

But please keep in mind that all this stuff has just been set over time in
a reactionary/evolutionary process to keep things running smoothly, rather
than something which was designed and formalised by a committee in advance.
There's always room for improvement and revision to match current needs! 👍

On Sat, 14 Oct 2023 at 05:43, Sandro Santilli via QGIS-Developer <
qgis-developer@lists.osgeo.org> wrote:
>
> It's not just me, I think, but I cannot tell for sure because the
configuration
> of the infrastructure currently in use (github) is not available for me
to see
> and the governance page on the official QGIS website does not contain this
> information [2]. This being blind of course adds up to my frustration.

This page **definetly** needs an update. There's information on that page
which is ~decades out of date (eg Larry Shaffer hasn't been involved in the
project for around 10 years, the OSX packaging team is incorrect, and the
whole "testing" team is non-existent, etc).

I'm happy to help out here with removing old content. My gut feeling is
that a more exhaustive rework is needed and repository / process related
information doesn't belong on this page, and the page should be left to the
"organisation" level governance information alone.

> From experience, I know that the reason why I cannot write to the QGIS
> repository is because "branch protection" is active (for the master branch
> at least) and a set of conditions are required to merge a PR, namely:
>
>   - All CI tests need to pass.
>
>   - Someone else (I don't know from which group of people) needs to
> approve the proposed change.

Correct. And I would argue that both of these requirements are a valid
**MINIMUM** protection choice for introducing code into a project which has
real world cost impacts for users exceeding millions and potentially
impacting the lives and safety of others.

> 1. CI is often broken for reasons that are independent from the proposed
>change.

Definitely a valid issue, and a real PITA. I'm probably restarting that
mingw workflow ~20x a day for everyone's(!) PRs to keep it limping along.

That said, I'd still rather limp this workflow along vs removing it,
because I do believe that it adds value to our tests and gives end users an
easy way to test PRs prior to merge. I feel the same about the noisy
clang-tidy check: it has a LOT of false positives, but around 1 in 10
failures in that workflow is a valid bug which has been flagged prior to
introducing the code. That's still a net win in my view.

> 2. An aberration of the "review" condition is that a change proposed by a
>contributor and approved by me can be merged but a change proposed by
>me and approved by the same contributor can not be merged, effectively
>giving me ("core QGIS committer") less power than the power of a random
>contributor.

Maybe -- but I would argue that you're looking at the "core contributor"
privilege incorrectly. It's no longer a "you are trusted to put whatever
code you want into the project" vs a "you are trusted to peer review and
approve code proposed for introduction into the project".

Ie **everyone** is on the same level wrt to submitting code for review, but
only the trusted group of core committers are permitted to approve this
code for introduction to QGIS.

>   1. Clearly document the roles and rules on the website

+1

>   2. Allow those with "write access" to self-approve PRs

-1. What's the real motivation here? Why the urgency to get unreviewed code
into QGIS? Again, I am strongly of the opinion that more exhaustive code
merging policies protects our users and their trust in QGIS.

>   3. Define rules by which "write access" privileges to the repository
>  are revoked

+1

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] Dropping "render" checkbox from status bar

[Nyall Dawson via QGIS-Developer]

Hi list,

Question: are there still any valid use cases for the "render"
checkbox in the status bar? It's been around forever, and DID have a
strong use case when map rendering used to block the QGIS interface.
But is there any reason to keep this around in modern QGIS versions?

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] pygdaltools library documentation sparce

[Nyall Dawson via QGIS-Developer]

On Wed, 11 Oct 2023 at 15:15, Catania, Luke A ERDC-RDE-GRL-VA CIV via
QGIS-Developer  wrote:

>
> Anyone use pygdaltools?

You're better off asking this on the GDAL-Dev list, rather than QGIS-Dev.

Nyall

>
>
>
>
>
> import gdaltools
>
> gdal_tools = gdaltools.ogr2ogr()
>
> gdal_tools.BASEPATH = r"C:\Program Files\QGIS 3.16.16\bin"
>
>
>
> gdal_tools.set_encoding("UTF-8")
>
> gdal_tools.set_input(self.dxf_out_path)
>
> gdal_tools.set_output(self.gpkg_out)
>
> gdal_tools.execute()
>
>
>
> And I get the ERROR:root:b"Warning 1: Layer creation options ignored since an 
> existing layer is\r\n being appended to.\r\nWarning 6: 
> Normalized/laundered field name: 'EntityHandle' to 'EntityHa_2'\r\nERROR 1: 
> Attempt to write non-linestring (GEOMETRYCOLLECTION) geometry to ARC type 
> shapefile.\r\nERROR 1: Unable to write feature 0 from layer 
> entities.\r\nERROR 1: Terminating translation prematurely after 
> failed\r\ntranslation of layer entities (use -skipfailures to skip 
> errors)\r\n"
>
> Traceback (most recent call last):
>
>   File 
> "c:\Users\RDTECLAC\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins\site_selection\tools\master_planning\load_mp_designs.py",
>  line 227, in 
>
> main()
>
>   File 
> "c:\Users\RDTECLAC\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins\site_selection\tools\master_planning\load_mp_designs.py",
>  line 196, in main
>
> mp_designs.gdal_convert()
>
>   File 
> "c:\Users\RDTECLAC\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins\site_selection\tools\master_planning\load_mp_designs.py",
>  line 185, in gdal_convert
>
> gdal_tools.execute()
>
>   File 
> "C:\Users\RDTECLAC\AppData\Roaming\Python\Python39\site-packages\gdaltools\ogr2ogrcmd.py",
>  line 330, in execute
>
> return self._do_execute(args)
>
>   File 
> "C:\Users\RDTECLAC\AppData\Roaming\Python\Python39\site-packages\gdaltools\basetypes.py",
>  line 108, in _do_execute
>
> raise GdalToolsError(rc, err)
>
> gdaltools.basetypes.GdalToolsError: (1, b"Warning 1: Layer creation options 
> ignored since an existing layer is\r\n being appended to.\r\nWarning 
> 6: Normalized/laundered field name: 'EntityHandle' to 'EntityHa_2'\r\nERROR 
> 1: Attempt to write non-linestring (GEOMETRYCOLLECTION) geometry to ARC type 
> shapefile.\r\nERROR 1: Unable to write feature 0 from layer 
> entities.\r\nERROR 1: Terminating translation prematurely after 
> failed\r\ntranslation of layer entities (use -skipfailures to skip 
> errors)\r\n")error:
>
>
>
>
>
> ___
> 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] Next QGIS LTR and its compatibility with older versions

[Nyall Dawson via QGIS-Developer]

On Tue, 3 Oct 2023 at 00:45, Greg Troxel via QGIS-Developer
 wrote:
>
> Andreas Neumann via QGIS-Developer 
> writes:

>
> My impression is also that 3.30, 3.32 are stable and entirely usable for
> users.

Small clarification here: the 3.x.0 releases AREN'T considered stable,
you should wait for 3.x.1 before targeting the newer release.

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] Next QGIS LTR and its compatibility with older versions

[Nyall Dawson via QGIS-Developer]

On Tue, 3 Oct 2023 at 00:16, Andreas Neumann via QGIS-Developer
 wrote:

> About your second question: don't nail me down on this but all 3.x versions 
> should open with the newest 3.x version - it should be even possible to open 
> version 2 files with the latest 3.x version.

It's definite! If you run into issues opening a project made in an
older 3.x version in a newer QGIS version, then it's a bug which must
be fixed!

Nyall


>
> Greetings,
>
> Andreas
>
> On 2023-10-02 15:57, Raffael Meier via QGIS-Developer wrote:
>
> Hello
>
>
>
> I would like to know if this is correct, that the next long term release of a 
> stable QGIS version (3.34.0) will be at the end of October 2023?
>
> If this is correct I would like to know if I worked with an older version and 
> I want to continue working on this project with the upcoming LTR what ist he 
> oldest QGIS version files that
>
> I can still use with the new LTR (3.34.0).
>
>
>
> Best regards,
>
> Raffael
>
>
>
>
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] LTR version info in version.txt?

[Nyall Dawson via QGIS-Developer]

On Wed, 13 Sept 2023 at 16:54, Jürgen E. Fischer via QGIS-Developer
 wrote:

> Simple.
> https://github.com/qgis/QGIS-Website/commit/23da801f7c186d3c796d6e1407a17b959c92a3d6

Brilliant! Thanks so much Jürgen!

Nyall

>
> {
> "latest": {
> "versionint": 33202,
> "version": "3.32.2",
> "name": "Lima",
> "note": "\u200b",
> "binary": "1",
> "date": "2023-08-18",
> "major": 3,
> "minor": 32,
> "patch": 2
> },
> "ltr": {
> "versionint": 32810,
> "version": "3.28.10",
> "name": "Firenze",
> "note": "LTR",
> "binary": "1",
> "date": "2023-08-18",
> "major": 3,
> "minor": 28,
> "patch": 10
> },
> "dev": {
> "version": "3.33",
> "versionint": 33300,
> "major": 3,
> "minor": 33,
> "patch": 0
> },
> "freezedate": "2023-09-15 12:00:00 UTC",
> "nextreleasedate": "2023-10-27 12:00:00 UTC",
> "nextversion": "3.34"
> }
>
>
> 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 Nordenhttps://www.norbit.de
> QGIS release manager (PSC)  Germany IRC: jef on Libera|OFTC
> ___
> 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] LTR version info in version.txt?

[Nyall Dawson via QGIS-Developer]

On Wed, 13 Sept 2023 at 16:23, Richard Duivenvoorde 
wrote:

>
> https://github.com/qgis/QGIS-Website/blob/master/scripts/mkversion.py
>
> I think it is used for the about box. Juergen is handling this
>

Thanks Richard! I think I got confused because my local LTR build is
hitting up the https://version.qgis.org/version.txt instead of
https://version.qgis.org/version-ltr.txt
<https://version.qgis.org/version.txt> , and I can't see anywhere in
https://github.com/qgis/QGIS/blob/release-3_28/src/app/qgsversioninfo.cpp
where the url is changed from version.txt to version-ltr.txt.

Is this a manual thing done during packaging?

Nyall



>
> Regards,
>
> Richard Duivenvoorde
>
> On 9/13/23 05:50, Nyall Dawson via QGIS-Developer wrote:
> > Hi list,
> >
> > Has something changed in the format of
> https://version.qgis.org/version.txt <https://version.qgis.org/version.txt>
> recently? It used to be that this file included a string "current LTR
> version of QGIS is ", but that's no longer present and I can only see
> the 3.32 release details now.
> >
> > (on a related note... would it be tricky to make a "version.json"
> equivalent of this file with content like
> > {
> >  'latest': {'major': 3, 'minor': 32, 'subversion': 3 },
> >  'ltr': {'major': 3, 'minor': 28, 'subversion': 10 }
> > } ? )
> >
> > 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] LTR version info in version.txt?

[Nyall Dawson via QGIS-Developer]

Hi list,

Has something changed in the format of https://version.qgis.org/version.txt
recently? It used to be that this file included a string "current LTR
version of QGIS is ", but that's no longer present and I can only see
the 3.32 release details now.

(on a related note... would it be tricky to make a "version.json"
equivalent of this file with content like
{
'latest': {'major': 3, 'minor': 32, 'subversion': 3 },
'ltr': {'major': 3, 'minor': 28, 'subversion': 10 }
} ? )

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] Proposal: Core committer rights for Andrea Giudiceandrea

[Nyall Dawson via QGIS-Developer]

Hi PSC,

I'd like to propose that core committer rights are granted to Andrea
Giudiceandrea (@agiudiceandrea, https://github.com/agiudiceandrea ).

Andrea has been active in QGIS c++ development for the last 5 years,
and has a fantastic track record of contributions. Their contributions
demonstrate all the qualities we need for core contributors --
attention to detail, careful consideration of the ramifications of
changes, and a very clear dedication to making QGIS a better
experience for end users. Time and time again, they've shown a
willingness to just jump in and fix things directly, and QGIS would
not be the application it is today without their contributions.

Thanks for your consideration!
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] Commit 1dca9b9 breaks build on FreeBSD with clang

[Nyall Dawson via QGIS-Developer]

On Fri, 11 Aug 2023 at 15:54, Rainer Hurling  wrote:
>
> Am 11.08.23 um 05:07 schrieb Nyall Dawson:
> > On Thu, 10 Aug 2023 at 23:20, Rainer Hurling  wrote:
> >>
> >> Hi Nyall,
> >>
> >> On FreeBSD, commit 1dca9b9 [1] breaks the build with clang 16.0.6:
> >
> > Ouch! If it's causing issues then it's fine to revert, it won't harm 
> > anything.
>
> I just double checked. Without commit 1dca9b9 I am able to build latest
> version (atm commit 1a44f7b) on FreeBSD.
>
> If it would be okay with you, the commit would be best withdrawn. On the
> other hand, if there are no problems with your patch for other systems,
> I can also use an appropriate (revert) patch for the port in FreeBSD.
>

Reverted in b797724607, thanks!
Nyall

> Rainer
>
> >
> > Nyall
> >
> >
> >>
> >> In file included from
> >> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/mocs_compilation.cpp:132:
> >> In file included from
> >> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgscopcpointcloudindex.cpp:10:
> >> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/../../../../../QGIS-1dca9b9/src/core/pointcloud/qgscopcpointcloudindex.h:109:22:
> >> error: no type named 'copc_info_vlr' in namespace 'lazperf'
> >>   mutable lazperf::copc_info_vlr mCopcInfoVlr;
> >>   ~^
> >> In file included from
> >> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/mocs_compilation.cpp:132:
> >> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgscopcpointcloudindex.cpp:86:32:
> >> error: cannot initialize object parameter of type 'QgsPointCloudIndex'
> >> with an expression of type 'QgsCopcPointCloudIndex'
> >>   return QgsPointCloudIndex::qt_metacast(_clname);
> >>  ^~~
> >> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgscopcpointcloudindex.cpp:91:31:
> >> error: cannot initialize object parameter of type 'QgsPointCloudIndex'
> >> with an expression of type 'QgsCopcPointCloudIndex'
> >>   _id = QgsPointCloudIndex::qt_metacall(_c, _id, _a);
> >> ^~~
> >> In file included from
> >> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/mocs_compilation.cpp:144:
> >> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgsremotecopcpointcloudindex.cpp:86:36:
> >> error: cannot initialize object parameter of type
> >> 'QgsCopcPointCloudIndex' with an expression of type
> >> 'QgsRemoteCopcPointCloudIndex'
> >>   return QgsCopcPointCloudIndex::qt_metacast(_clname);
> >>  ^~~
> >> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgsremotecopcpointcloudindex.cpp:91:35:
> >> error: cannot initialize object parameter of type
> >> 'QgsCopcPointCloudIndex' with an expression of type
> >> 'QgsRemoteCopcPointCloudIndex'
> >>   _id = QgsCopcPointCloudIndex::qt_metacall(_c, _id, _a);
> >> ^~~
> >> 5 errors generated.
> >> gmake[4]: *** [src/core/CMakeFiles/qgis_core.dir/build.make:1557:
> >> src/core/CMakeFiles/qgis_core.dir/qgis_core_autogen/mocs_compilation.cpp.o]
> >> Error 1
> >> gmake[4]: Leaving directory '/usr/ports/graphics/qgis-devel/work/.build'
> >> gmake[3]: *** [CMakeFiles/Makefile2:4696:
> >> src/core/CMakeFiles/qgis_core.dir/all] Error 2
> >> gmake[3]: Leaving directory '/usr/ports/graphics/qgis-devel/work/.build'
> >> gmake[2]: *** [Makefile:169: all] Error 2
> >> gmake[2]: Leaving directory '/usr/ports/graphics/qgis-devel/work/.build'
> >> *** Error code 1
> >>
> >>
> >> -
> >> [1]
> >> https://github.com/qgis/QGIS/commit/1dca9b9dbc9c790d627e8112adae7333c7a450f7
> >>
> >> Any ideas? Many thanks for any help.
> >>
> >> Best regards,
> >> Rainer Hurling, maintainer of the FreeBSD port of QGIS
>
___
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] Commit 1dca9b9 breaks build on FreeBSD with clang

[Nyall Dawson via QGIS-Developer]

On Thu, 10 Aug 2023 at 23:20, Rainer Hurling  wrote:
>
> Hi Nyall,
>
> On FreeBSD, commit 1dca9b9 [1] breaks the build with clang 16.0.6:

Ouch! If it's causing issues then it's fine to revert, it won't harm anything.

Nyall


>
> In file included from
> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/mocs_compilation.cpp:132:
> In file included from
> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgscopcpointcloudindex.cpp:10:
> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/../../../../../QGIS-1dca9b9/src/core/pointcloud/qgscopcpointcloudindex.h:109:22:
> error: no type named 'copc_info_vlr' in namespace 'lazperf'
>  mutable lazperf::copc_info_vlr mCopcInfoVlr;
>  ~^
> In file included from
> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/mocs_compilation.cpp:132:
> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgscopcpointcloudindex.cpp:86:32:
> error: cannot initialize object parameter of type 'QgsPointCloudIndex'
> with an expression of type 'QgsCopcPointCloudIndex'
>  return QgsPointCloudIndex::qt_metacast(_clname);
> ^~~
> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgscopcpointcloudindex.cpp:91:31:
> error: cannot initialize object parameter of type 'QgsPointCloudIndex'
> with an expression of type 'QgsCopcPointCloudIndex'
>  _id = QgsPointCloudIndex::qt_metacall(_c, _id, _a);
>^~~
> In file included from
> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/mocs_compilation.cpp:144:
> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgsremotecopcpointcloudindex.cpp:86:36:
> error: cannot initialize object parameter of type
> 'QgsCopcPointCloudIndex' with an expression of type
> 'QgsRemoteCopcPointCloudIndex'
>  return QgsCopcPointCloudIndex::qt_metacast(_clname);
> ^~~
> /usr/ports/graphics/qgis-devel/work/.build/src/core/qgis_core_autogen/FIPKY4Q6PV/moc_qgsremotecopcpointcloudindex.cpp:91:35:
> error: cannot initialize object parameter of type
> 'QgsCopcPointCloudIndex' with an expression of type
> 'QgsRemoteCopcPointCloudIndex'
>  _id = QgsCopcPointCloudIndex::qt_metacall(_c, _id, _a);
>^~~
> 5 errors generated.
> gmake[4]: *** [src/core/CMakeFiles/qgis_core.dir/build.make:1557:
> src/core/CMakeFiles/qgis_core.dir/qgis_core_autogen/mocs_compilation.cpp.o]
> Error 1
> gmake[4]: Leaving directory '/usr/ports/graphics/qgis-devel/work/.build'
> gmake[3]: *** [CMakeFiles/Makefile2:4696:
> src/core/CMakeFiles/qgis_core.dir/all] Error 2
> gmake[3]: Leaving directory '/usr/ports/graphics/qgis-devel/work/.build'
> gmake[2]: *** [Makefile:169: all] Error 2
> gmake[2]: Leaving directory '/usr/ports/graphics/qgis-devel/work/.build'
> *** Error code 1
>
>
> -
> [1]
> https://github.com/qgis/QGIS/commit/1dca9b9dbc9c790d627e8112adae7333c7a450f7
>
> Any ideas? Many thanks for any help.
>
> Best regards,
> Rainer Hurling, maintainer of the FreeBSD port of QGIS
___
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] Adding a plugin collaborator

[Nyall Dawson via QGIS-Developer]

On Mon, 26 Jun 2023 at 14:01, Richard Duivenvoorde  wrote:
>
> On 6/26/23 00:55, Nyall Dawson wrote:
> > Thanks Richard, I've found this setting now! (For other's reference it's 
> > under "Manage" - "Edit" - "Owners").
> >
> > It's a bit clunky unfortunately -- there's a list box with over 4000 
> > entries and I need to safely select multiple entries from this 😂...  I 
> > think I'll resort to some js console trickery to make sure I do it 
> > correctly!
>
> Yeah, you are right... it's was OK in the beginning of our plugins... or if 
> you want to select just one, but in your case..
>
> This is the repo of the site: https://github.com/qgis/QGIS-Django/
>
> Feel free to add a Feature Request to easier filter or multi select that list.

In case it's useful for anyone else, here's the little script I used
to easily set a bunch of owners:

owners_input = document.getElementById('id_owners')
const users = ["some_user", "another_user", "another_person"];
for (var i = 0; i < owners_input.options.length; i++) {
if ( users.includes(owners_input.options[i].text))
{
  console.log(owners_input.options[i].text);
  owners_input.options[i].selected = true;
}
else
{
  owners_input.options[i].selected = false;
}
}

Nyall



>
> Regards,
>
> Richard
___
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] Adding a plugin collaborator

[Nyall Dawson via QGIS-Developer]

On Thu, 22 Jun 2023 at 17:08, Richard Duivenvoorde 
wrote:
>
> On 2023-06-22 06:34, Nyall Dawson via QGIS-Developer wrote:
> > Hi list,
> >
> > This is possibly a stupid question -- but how can I add additional
> > users as collaborators to a plugin via https://plugins.qgis.org/?
> >
> > I can see other plugins which have done this, but can't see any
> > settings exposed in my plugins which permit me to add collaborations
> > myself.
>
> As admin it it possible to change 'owners'. That is if the ownership
> changes, I (or other admins) can do that in the plugins.qgis.org site.

Thanks Richard, I've found this setting now! (For other's reference it's
under "Manage" - "Edit" - "Owners").

It's a bit clunky unfortunately -- there's a list box with over 4000
entries and I need to safely select multiple entries from this 😂...  I
think I'll resort to some js console trickery to make sure I do it
correctly!

Nyall




>
> For metadata fields:
>
https://docs.qgis.org/3.28/en/docs/pyqgis_developer_cookbook/plugins/plugins.html#metadata-txt
>
> Not sure what you mean with collaborator?
> Can you give an example of such 'collaborator'?
>
> Or if you let me know, I dan make a person 'owner' too...
>
> 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

[QGIS-Developer] Adding a plugin collaborator

[Nyall Dawson via QGIS-Developer]

Hi list,

This is possibly a stupid question -- but how can I add additional
users as collaborators to a plugin via https://plugins.qgis.org/?

I can see other plugins which have done this, but can't see any
settings exposed in my plugins which permit me to add collaborations
myself.

Does it require some administrative privileges to do this?

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] QgsProjectStyleSettings styles.db remain open after QgsProject::clear()

[Nyall Dawson via QGIS-Developer]

On Mon, 12 June 2023, 8:32 pm Radim Blazek,  wrote:

> QCoreApplication.sendPostedEvents(None, QEvent.DeferredDelete) does the
> job.
>

https://github.com/qgis/QGIS/pull/53400 will have helped here too! (At this
stage I'm not planning on backporting that though)

Nyall

>
> Thanks
> Radim
>
> On Tue, Apr 18, 2023 at 10:38 AM Nyall Dawson 
> wrote:
> > You can safely execute the event loop with DeferredDelete to only
> cleanup of this object without the danger of other event loop mess.
>
___
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] Call of testing of nightlies on hi-dpi displays

[Nyall Dawson via QGIS-Developer]

On Mon, 29 May 2023 at 19:23, Richard Duivenvoorde  wrote:
>
> Hi Nyall,
>
> Happy to do some testing, I do have a (dual boot) laptop/tablet with 
> 3000x2000 screen (that's high-dpi, yes?), but in Gnome I set the Display 
> 'Scale' on 200% to have proper applications (an to me readable text :-) ).
>
> Is there some test plan/idea's?

There's a few things in particular we need to identify:

- Widgets which are now showing as pixelated. Basically just hunt
through the UI looking for things which look pixelated! This might be
icons, graphics, or even just the drawing of the widget itself. You'll
spot them immediately, as they clearly stand out. But there's a LOT of
different dialogs/tabs/widgets/pages/... in QGIS and it will take some
time to hunt through them all.
- Icons/images which look the wrong size. Eg the marker symbols shown
in the layer tree right now are incorrectly sized and will be half the
size of the actual symbol shown on the map. That's a known regression,
but there's likely others like this hiding around the place.
- Text which is the wrong size. If something has a hard-coded sizing
it's possible that we'll get fonts scaled badly, so if you spot any
text which noticably looks incorrectly sized vs other UI elements then
that's also something we need to fix.

> Is my setup something you want to test (200%), or is is preferred to use the 
> 100% scale?

This is EXACTLY the kind of setup we need testing on! If the display
scaling is set to 100% (in Windows, or Linux), then you'll see no
difference between the old approach vs new. The new logic only kicks
in when display scaling is present.

> I'm not sure what is supposed to be the 'normal' way of scaling (like what 
> does a mac do)?

Things should just look perfect, regardless of whether or not display
scaling is active :)

Nyall

> Or is it more to try to see if the icons/widgets scale up/down when fidling 
> with scale (or what it is called in Windows)?
>
> Regards,
>
> Richard Duivenvoorde
>
> On 5/29/23 06:01, Nyall Dawson via QGIS-Developer wrote:
> > Hi lists,
> >
> > For the upcoming QGIS 3.32 release a change has been made in how QGIS
> > handles high dpi (and retina) displays. This should ultimately make
> > QGIS behave MUCH better on these displays, but there's likely some
> > short-term fallout and regressions caused by the change.
> >
> > If you've access to a high-dpi display, please test out the nightly
> > releases and file bug reports on github for any regressions you spot
> > -- in particular we are looking for widgets and places where the QGIS
> > interface is now looking pixelated or where the scale / sizes of
> > objects are incorrect.
> >
> > (Currently there's known regressions for the icons shown in the layer
> > tree panel, and for pixelated icons in the style manager dialog.)
> >
> > Thanks in advance!
> > 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] Call of testing of nightlies on hi-dpi displays

[Nyall Dawson via QGIS-Developer]

Hi lists,

For the upcoming QGIS 3.32 release a change has been made in how QGIS
handles high dpi (and retina) displays. This should ultimately make
QGIS behave MUCH better on these displays, but there's likely some
short-term fallout and regressions caused by the change.

If you've access to a high-dpi display, please test out the nightly
releases and file bug reports on github for any regressions you spot
-- in particular we are looking for widgets and places where the QGIS
interface is now looking pixelated or where the scale / sizes of
objects are incorrect.

(Currently there's known regressions for the icons shown in the layer
tree panel, and for pixelated icons in the style manager dialog.)

Thanks in advance!
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] Non-cartesian buffering

[Nyall Dawson via QGIS-Developer]

On Thu, 25 May 2023 at 10:27, Alexis R.L. via QGIS-Developer
 wrote:
>
> Greetings,
>
> I was looking into buffers and noticed that arc could do geoid buffering but 
> it's not something qgis could do yet.
>
> Now I'm going to assume that such a thing would usually need to be 
> implemented in geos and in one of the ticket asking about this, another 
> repository was pointed to ( https://github.com/libgeos/geos/issues/820).
>
> That repository being https://github.com/google/s2geometry now I don't know 
> how important generating things based on non-cartesian distance is and if 
> such tools are to be made if they should be made in QGIS instead of relying 
> on external libs.

Unfortunately S2 isn't a sufficiently generic approach in my opinion.
It is designed completely around a spherical earth assumption, so
doesn't work for situations where an ellipsoidal model is required
(and definitely doesn't work for non-earth bodies).

What we need is a library which can perform geographic buffering using
an ellipsoid. Which doesn't exist yet, but
https://geographiclib.sourceforge.io/ would be a good place for this
to exist...

Nyall




>
> As more and more global and 3D things are added,I assume that those will be 
> more important.
>
> Thanks,
>
> Alex
> ___
> 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] 2023 grant applications are now closed

[Nyall Dawson via QGIS-Developer]

Thanks Anita!

On Fri, 5 May 2023, 4:44 am Anita Graser via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

>
> 8. Unify the geometric and topological verification and correction
> features in QGIS -
> https://github.com/qgis/QGIS-Enhancement-Proposals/issues/262
>

This link points to a different proposal, and I can't work out which is the
correct one. Was a qep submitted for this grant?

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] PSA: Don't update to Gnome 44!

[Nyall Dawson via QGIS-Developer]

Hi lists,

Just a quick PSA: If you're using QGIS (or any Qt based app), I recommend
avoiding an upgrade to any gnome 44 based distribution for now.

You'll get hit with this nasty bug:
https://gitlab.gnome.org/GNOME/mutter/-/issues/2715 which breaks drag and
drop functionality in all Qt applications. And in the process, basically
makes QGIS unusable... 😱

You've been warned!

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] Customizing Layer Panel

[Nyall Dawson via QGIS-Developer]

On Thu, 27 Apr 2023 at 07:42, Catania, Luke A ERDC-RDE-GRL-VA CIV via
QGIS-Developer  wrote:
>
> But I am looking to access the dock widget and add two icons in its row
of icons or maybe a menu.

It's not available via the stable API, but let's not let that stop us! 😆

layer_tree = iface.layerTreeView()
layer_tree_dock = layer_tree.parent().parent()
toolbar = layer_tree_dock.findChildren(QToolBar)[0]

my_action = QAction('something')
toolbar.addAction(my_action)

Nyall


>
>
>
> Thanks in advance for any help,
>
> Luke
>
> ___
> 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] [EXTERNAL] Re: Outdated WebKit engine version in QGIS

[Nyall Dawson via QGIS-Developer]

On Wed, 19 Apr 2023 at 16:55, Nguyen, Huy Minh  wrote:
>
> Hi,
>
> If Qt Webengine is in QGIS why it cannot be used ? Is there maybe any Qgs 
> class that uses Qt Webengine internally and can be reused ?

It's not in QGIS. It's in Qt, but can't be used from QGIS. QtWebengine
requires some initialization steps before construction of the
QApplication used by QGIS, and unfortunately these steps introduce an
incompatibility in OpenGL handling which breaks the QGIS 3D
functionality.

Pending an upstream Qt / Webengine fix we can't resolve this
situation, and Qt Webengine is not a possibility for use in QGIS.

Nyall


>
> Minh
>
>
> -Original Message-
> From: Nyall Dawson 
> Sent: Wednesday, April 19, 2023 7:28 AM
> To: Nguyen, Huy Minh 
> Cc: qgis-developer@lists.osgeo.org
> Subject: [EXTERNAL] Re: [QGIS-Developer] Outdated WebKit engine version in 
> QGIS
>
>
> On Wed, 19 Apr 2023 at 15:24, Nguyen, Huy Minh via QGIS-Developer 
>  wrote:
> >
> > Hi,
> >
> >
> >
> > I have been using WebKit engine from the PyQt library built in QGIS 3.30 
> > when developing QGIS plugin in Python to load web pages directly in QGIS. 
> > The Webkit engine used seems to be very outdated and not possible to render 
> > modern web pages. For example, the engine used in QGIS 3.30 dated back to 
> > 2016: AppleWebKit/602.1 (KHTML, like Gecko) QGIS3 Version/10.0 Safari/602.1.
> >
> >
> >
> > Is there any chance to update the built-in Webkit engine version in next 
> > release of QGIS ?
> >
> > Otherwise, can the WebKit engine be updated locally and provided to the 
> > application ?
> >
> > Does QGIS offer any other built-in alternatives, like the Qt WebEngine or 
> > other web engine with python bindings ?
>
> It's an extremely messy and painful situation, but ultimately the answer is 
> NO. There's no alternative, no way of updating the webkit version used by 
> QtWebkit, and Qt Webengine CANNOT be used as it stands in QGIS.
>
> Nyall
>
> >
> >
> >
> > Thank you,
> >
> > Minh
> >
> >
> >
> >
> >
> > ___
> > QGIS-Developer mailing list
> > QGIS-Developer@lists.osgeo.org
> > List info:
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.osgeo.org%2Fmailman%2Flistinfo%2Fqgis-developer&data=05%7C01%7Chuymi
> > nh.nguyen%40here.com%7C83865261759a4e94b02808db4096e273%7C6d4034cd7225
> > 4f72b85391feaea64919%7C0%7C0%7C638174789008955324%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > %7C3000%7C%7C%7C&sdata=zsajlNbGjcZdZMAp%2BnBCgSAP1Tap5O6Ni8WbFSvKsuE%3
> > D&reserved=0
> > Unsubscribe:
> > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> > s.osgeo.org%2Fmailman%2Flistinfo%2Fqgis-developer&data=05%7C01%7Chuymi
> > nh.nguyen%40here.com%7C83865261759a4e94b02808db4096e273%7C6d4034cd7225
> > 4f72b85391feaea64919%7C0%7C0%7C638174789008955324%7CUnknown%7CTWFpbGZs
> > b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D
> > %7C3000%7C%7C%7C&sdata=zsajlNbGjcZdZMAp%2BnBCgSAP1Tap5O6Ni8WbFSvKsuE%3
> > D&reserved=0
> LEARN FAST: This email originated outside of HERE.
> Please do not click on links or open attachments unless you recognize the 
> sender and know the content is safe. 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

Re: [QGIS-Developer] Outdated WebKit engine version in QGIS

[Nyall Dawson via QGIS-Developer]

On Wed, 19 Apr 2023 at 15:24, Nguyen, Huy Minh via QGIS-Developer
 wrote:
>
> Hi,
>
>
>
> I have been using WebKit engine from the PyQt library built in QGIS 3.30 when 
> developing QGIS plugin in Python to load web pages directly in QGIS. The 
> Webkit engine used seems to be very outdated and not possible to render 
> modern web pages. For example, the engine used in QGIS 3.30 dated back to 
> 2016: AppleWebKit/602.1 (KHTML, like Gecko) QGIS3 Version/10.0 Safari/602.1.
>
>
>
> Is there any chance to update the built-in Webkit engine version in next 
> release of QGIS ?
>
> Otherwise, can the WebKit engine be updated locally and provided to the 
> application ?
>
> Does QGIS offer any other built-in alternatives, like the Qt WebEngine or 
> other web engine with python bindings ?

It's an extremely messy and painful situation, but ultimately the
answer is NO. There's no alternative, no way of updating the webkit
version used by QtWebkit, and Qt Webengine CANNOT be used as it stands
in QGIS.

Nyall

>
>
>
> Thank you,
>
> Minh
>
>
>
>
>
> ___
> 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] QgsProjectStyleSettings styles.db remain open after QgsProject::clear()

[Nyall Dawson via QGIS-Developer]

On Tue, 18 Apr 2023, 6:34 pm Radim Blazek via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hi,
> with Qgis 3.28.3 called from Python, whenever QgsProject::clear() is
> called it creates new styles.db file, previous styles file is deleted
> from system, but it remains open (listed by lsof). It becomes a
> problem in server environment where every call to QgsProject::clear()
> creates a new file and limit of open files is soon reached.
>
> Just reading the code I was not able to trace down where / which
> object remains referenced. Maybe QgsStyle.mCurrentDB should be closed
> explicitly?
>

It will only get freed when the event loop is next executed.

You can safely execute the event loop with DeferredDelete to only cleanup
of this object without the danger of other event loop mess.

Nyall


> Is it OK to use this workaround?:
> project = QgsProject(None, Qgis.ProjectCapabilities())
> QgsProject.setInstance(project)
>
> BTW, how can I modify QgsProject.capabilities() from Python?
>
> Radim
> ___
> 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] Temporarily disable map canvas right click showing Copy Coordinates

[Nyall Dawson via QGIS-Developer]

On Thu, 13 Apr 2023 at 10:47, Catania, Luke A ERDC-RDE-GRL-VA CIV via
QGIS-Developer  wrote:
>
> I have an event filter on the map canvas that performs a commit during 
> feature editing when right clicking on the canvas.  While this performs the 
> commit, it then pops up Copy Coordinates.  I don’t want the user to see this. 
>  I want my mouse click event to be recognized and not have QGIS use it to 
> popup the Copy Coordinates.  Is there a way to call QgsMapTool.deactivate on 
> that built in tool just for this instance and then reactivate it?

Are you using a custom QgsMapTool subclass? If so, implement the
"flags" method and don't return the ShowContextMenu flag.

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] sip-build takes too long to complete

[Nyall Dawson via QGIS-Developer]

On Thu, 6 Apr 2023 at 03:03, Julien Cabieces via QGIS-Developer
 wrote:
>
>
> Hi,
>
> While working on building QGIS python binding with SIP 6/PyQT6, it seems
> to me that it takes more time than my classic setup (SIP 4.19.25/PyQT
> 5.15.7) but no as much as you describe.

This matches my findings -- sip 6 is much slower than sip 4.

That said, ~10 minutes to build is dramatically longer than I see on
sip 6. On 6.6.2 the sip builds might take ~30 seconds for me. (Fedora
37)

Nyall


>
> You can try to downgrade your SIP version. I'm also on debian testing
> and current python3-sip version is 4.19.25). Did you install it with
> pip?
>
> Regards,
> Julien
>
> > Hi list,
> > lately, while building QGIS with any sip related change, some of the 
> > triggered `sip-build` processes take too long to complete (two of them take 
> > 10 minutes,
> > one takes 15' and one takes 25' roughly)
> > Is this normal or is it some quirk on my setup? (Debian testing, sip 6.7.7)
> >
> > Thanks,
> > Stefanos
> >
> > ___
> > 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
>
>
> --
>
> Julien Cabieces
> Senior Developer at Oslandia
> julien.cabie...@oslandia.com
> 09.72.52.52.76
> ___
> 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] QtCreator QGIS debugging not showing values

[Nyall Dawson via QGIS-Developer]

On Fri, 31 Mar 2023, 7:17 pm Richard Duivenvoorde via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hi Devs,
>
> Trying to look into one of my own issues (wrong timestep count for mesh
> layers #48942), I fail to see the values of variables in QtCreator see
> screendump.
> I tried to fiddle with Debuggers (gdb -> lldb), helpers, gdb properties
> (Load system GDB pretty printers) etc etc. But I fail to see anything. Or
> getting frequent qgis crashes from withing qtcreator...
>
> Does this 'just work' with others? Or is everybody on Fedora now, or
> should I learn to debug from terminal :-)?
> Any clue for me?
>

It's a bug in qt creator with newer python versions. See
https://bugreports.qt.io/plugins/servlet/mobile#issue/QTCREATORBUG-28659

There's a patch in that ticket which you can apply (doesn't require
compiling) which resolves it.

Nyall



> My environment:
> Debian testing
> Qt 5.15.8
> Qt Creator 9.0.2 (based on Qt 6.4.2)
> GNU gdb (Debian 13.1-2) 13.1
>
> 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
>
___
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] QGIS QT6 meeting minutes

[Nyall Dawson via QGIS-Developer]

On Wed, 15 Mar 2023 at 18:45, Julien Cabieces via QGIS-PSC
 wrote:
>
>
> Hi,
>
> Thank you for the meeting minutes!
>
> I'm already planning to continue the effort in
> porting/fixing code for Qt6 in the next months using Oslandia own
> funding, so I'm candidate to join the working group.
>
> > ND: major missing bit: python support. Bulk of the tests are thus not 
> > running
> > Packaging issues - Sandro Mani looking into python stuff for fedora
> > (QVariant issues)
>
> Is there a reason why we are switching from ubuntu for Qt5 builds to
> fedora for Qt6 builds ? Because there is already PyQt6 packages in 
> ubuntu:22.10.

Initially Fedora was the *only* platform offering qt6 binaries, so all
the CI setup was done using that. But now that Ubuntu/etc have caught
up I still think it's a good idea to leave the CI with Fedora so that
we get a better spread of testing environments. (Fedora generally has
much more recent gdal/geos/proj/etc so by running CI on this
environment we're more likely to catch issues/test differences across
a wider range of library versions)

Nyall


>
> Regards,
> Julien
>
>
>
> > Hi,
> >
> > Here is some feedback about the QGIS QT6 status meeting we had yesterday.
> >
> > First I'd like to thank all the attendees, it was great to see the
> > excitement and the interest in moving forward with this project.
> >
> > If I may summarize the outcome, we decided that the best way to move
> > forward is to create a working group with all the interested
> > developers and allocate a budget (20K is the proposed budget) in order
> > to find a solution to the main blockers, it is very hard to estimate
> > the effort in advance but we thought that with that budget we will be
> > able to move forward.
> >
> > Any QGIS core developer with experience in the main areas involved and
> > willing to dedicate some time to this effort is eligible and warmly
> > invited to participate in the working group.
> >
> > Here is the link to the minutes:
> >
> > https://docs.google.com/document/d/1Un4Jyz9PO8t2vmEBkUKa187SytM2gsQn-jB6mSqXcvU/
> >
> > This proposal will be discussed at the next PSC meeting.
>
>
> --
>
> Julien Cabieces
> Senior Developer at Oslandia
> julien.cabie...@oslandia.com
> 09.72.52.52.76
> ___
> 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] Release 3.30 delayed

[Nyall Dawson via QGIS-Developer]

On Sat, 4 Mar 2023, 5:42 am Jürgen E. Fischer via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Hi,
>
> On Fri, 03. Mar 2023 at 16:15:04 +0100, Jürgen E. Fischer via
> QGIS-Developer wrote:
> > Sandy from transifex support just replied, that she's going to take this
> to the
> > engineers for a closer look and keep me posted.  hm.
>
> Well, didn't hear back yet - but I pushed the qgis_es.ts fetched from
> transifex
> yesterday back there and now it looks ok.
>

Thanks for your awesome efforts here Jürgen!

Are we ok to start merging again? Or hold off for now?

Nyall


>
> 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
> https://www.norbit.de
> QGIS release manager (PSC)  Germany IRC: jef on Libera|OFTC
> ___
> 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] Re-discussing the QGIS release schedule - in combination with the quarantine rule for LTR versions

[Nyall Dawson via QGIS-Developer]

On Tue, 28 Feb 2023 at 17:56, Andreas Neumann via QGIS-Developer
 wrote:
>
> Dear QGIS devs,
>
> The QGIS release schedule for LTR versions was recently "thinned out", as 
> part of a decision to introduce "manual testing" prior to release - see QEP 
> 239: https://github.com/qgis/QGIS-Enhancement-Proposals/issues/239 - see also 
> the release schedule at 
> https://www.qgis.org/en/site/getinvolved/development/roadmap.html
>
> Quote from the QEP 239: "LTR releases will no longer have monthly patch 
> releases, but instead a 4 months cycle releases, coincident with the release 
> of the stable version".
>
> I can understand the reasoning behind that decision, because "manual testing" 
> is a lot of work and it was also heard that many users don't install patch 
> releases too often.
>
> However, the situation is, that there is also a "quarantine rule" - which is 
> not mentioned in QEP 239 - but it helps to prevent untested patches to end up 
> in LTR versions, by delaying the backports until the backport was first 
> tested in the non-LTR stable release. There had been a number of examples 
> where this quarantine rule helped prevent regressions in the LTR version 
> introduced by backports in the past. So, I think this quarantine rule is 
> useful to have.
>
> However, it doesn't match well with the decision to "thin out" the release 
> schedule of the LTR version. There can be situations where a user will have 
> to wait 4-5 months, until a backport ends up in an LTR release, which is a 
> rather long time. We should bring this down to 2 months, like in the past.
>
> My proposal is to "revisit" the decision of the "thinned out" release 
> schedule and only "thin out", 6 months after a version became LTR.
>
> Any thoughts? Especially from the commercial support providers? How would 
> your customers react to the fewer patch releases?

I would VERY much like to see the current monthly LTR patch releases
continued for the lifetime of an LTR release. 4-5 months is just far
too long for users to wait for fixes.

Kind regards,
Nyall


>
> Thank you for the discussion,
> Andreas
>
> --
> Andreas Neumann
> QGIS.ORG board member (treasurer)
> ___
> 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] Additional python modules

[Nyall Dawson via QGIS-Developer]

On Sat, 25 Feb 2023, 1:24 am Yoann Quenach de Quivillic via QGIS-Developer,
 wrote:

> Hello everyone,
>
> I'm working on a new feature targeting 3.32 to reformat code written in
> the Python Console Editor : https://github.com/qgis/QGIS/pull/51733. It
> works great, but it requires additional python packages to be installed
> (namely black / autopep8 / isort).
>
> *Is there a reliable cross platform way we can use to distribute
> additional python packages alongside QGIS? *
>
> I could rewrite my PR to enable this feature only if the required modules
> are installed, but it seems kind of a shame... An alternative would be, as
> discussed in (
> https://github.com/qgis/QGIS/pull/51733#issuecomment-1434646910) to
> provide the end user a way to dynamically install modules as needed.
>


Black is a rather heavy library to add as a mandatory dependency, and it's
not safe to assume it's always available everywhere (eg last I checked it's
not available through the Fedora repos).

I think leaving the conditional checks is needed, but its definitely it's
worth exploring if the dependencies can be added to the default windows
install...

Nyall


> Any thoughts?
> Thanks,
>
> *--*
> *Yoann Quenach de Quivillic  *
> ___
> 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] Load a QgsMeshLayer within a QgsTask... different Threads?

[Nyall Dawson via QGIS-Developer]

On Thu, 9 Feb 2023, 6:18 pm Richard Duivenvoorde via QGIS-Developer, <
qgis-developer@lists.osgeo.org> wrote:

> Ok after reading
> https://docs.qgis.org/3.28/en/docs/pyqgis_developer_cookbook/tasks.html
> again, reading the warning:
>
> "Any background task (regardless of how it is created) must NEVER use any
> QObject that lives on the main thread, such as accessing QgsVectorLayer,
> QgsProject or perform any GUI based operations like creating new widgets or
> interacting with existing widgets. Qt widgets must only be accessed or
> modified from the main thread. Data that is used in a task must be copied
> before the task is started. Attempting to use them from background threads
> will result in crashes."
>

One thing you can do:

>From the thread which owns the object, when you've finished using that
object in the thread, call
object.moveToThread(QgsApplication.instance().thread())

You're allowed to push objects which belong to the current thread to
another thread, but never allowed to pull objects which belong to another
thread over to the current thread.

Nyall



> Seems to make it pretty clear :-(
>
> Before rereading that, I even tried to pass a QgsMeshLayer-'reference' to
> the QgsTask, but that did not work either.
>
> I think I must conclude that I just have to wait for the load... :-)
>
> Regards,
>
> Richard Duivenvoorde
>
>
>
> On 2/8/23 21:40, Richard Duivenvoorde via QGIS-Developer wrote:
> > Hi,
> >
> > Having to juggle with rather large/long loading netcdf files, I thought
> to off load the loading to a QgsTask, so while the netcdf was loaded user
> could do other things...
> >
> > But I get "...is run from a different thread than the object  lives in
> ..." warnings.
> >
> > In short:
> >
> >  def run(self) -> bool:
> >  log.info(f'LOADING... {self.netcdf_file}')
> >  try:
> >  self.layer = QgsMeshLayer(self.netcdf_file,
> 'PythonLoadedMeshLayer',  'mdal')
> >  
> >
> > BUT: while it looks like all is fine, I get a Qt warning in my messages,
> and on my terminal I get:
> >
> > [INFO] (Dummy-1   ) LOADING... /tmp/kees/aoi/aoi1/areaOfInterest1.nc
> > Warning: fileName
> (/home/richard/git/qgis/src/core/project/qgsproject.cpp:812) is run from a
> different thread than the object  lives in [0x5593004f1aa0 vs
> 0x5592ff7e6440]
> > Stacktrace (piped through c++filt):
> > /home/richard/bin/qgis_/master/debug/bin/qgis(+0xe26a)[0x5592fe9ba26a]
> > /home/richard/bin/qgis_/master/debug/bin/qgis(+0xea29)[0x5592fe9baa29]
> > /lib/x86_64-linux-gnu/libQt5Core.so.5(+0xc3b50)[0x7fc594ec3b50]
> > /lib/x86_64-linux-gnu/libQt5Core.so.5(qt_message_output(QtMsgType,
> QMessageLogContext const&, QString const&)+0xd)[0x7fc594ec50fd]
> >
> /lib/x86_64-linux-gnu/libQt5Core.so.5(QDebug::~QDebug()+0x68)[0x7fc594fc6fa8]
> >
> /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsProject::fileName()
> const+0x267)[0x7fc592f1af2f]
> >
> /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMapLayer::loadNamedProperty(QString
> const&, QgsMapLayer::PropertyType, bool&,
> QFlags)+0x752)[0x7fc592a215c0]
> >
> /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMapLayer::loadNamedStyle(QString
> const&, bool&, QFlags)+0x2b1)[0x7fc592a20b8f]
> >
> /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMapLayer::loadDefaultStyle(bool&)+0x2dc)[0x7fc592a1f6ec]
> >
> /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMeshLayer::loadDefaultStyle(bool&)+0x685)[0x7fc5930a84bb]
> >
> /home/richard/bin/qgis_/master/debug/lib/libqgis_core.so.3.29.0(QgsMeshLayer::QgsMeshLayer(QString
> const&, QString const&, QString const&, QgsMeshLayer::LayerOptions
> const&)+0x2b9)[0x7fc5930a5ab1]
> >
> /home/richard/bin/qgis_/master/debug/share/qgis/python/qgis/_core.so(sipQgsMeshLayer::sipQgsMeshLayer(QString
> const&, QString const&, QString const&, QgsMeshLayer::LayerOptions
> const&)+0x3b)[0x7fc43040b9c7]
> >
> /home/richard/bin/qgis_/master/debug/share/qgis/python/qgis/_core.so(+0x121a0bc)[0x7fc43041a0bc]
> > /usr/lib/python3/dist-packages/PyQt5/sip.cpython-311-x86_64-linux-gnu.so
> (+0x19f60)[0x7fc4dc271f60]
> > /lib/x86_64-linux-gnu/libpython3.11.so.1.0(+0x1e02fe)[0x7fc47a5e02fe]
> >
> /lib/x86_64-linux-gnu/libpython3.11.so.1.0(_PyObject_MakeTpCall+0x7d)[0x7fc47a57baed]
> >
> /lib/x86_64-linux-gnu/libpython3.11.so.1.0(_PyEval_EvalFrameDefault+0x4a63)[0x7fc47a509c63]
> > /lib/x86_64-linux-gnu/libpython3.11.so.1.0(+0x26a6da)[0x7fc47a66a6da]
> > /lib/x86_64-linux-gnu/libpython3.11.so.1.0(+0x17f30c)[0x7fc47a57f30c]
> > /usr/lib/python3/dist-packages/PyQt5/sip.cpython-311-x86_64-linux-gnu.so
> (+0x1196c)[0x7fc4dc26996c]
> > [INFO] (MainThread) finished OK
> >
> > My Questions:
> > - should I NOT do this?
> > - or is the loading/construction of a QgsMeshLayer having pointers to
> places it should not?
> >
> > (mmm loading a QgsVectorLayer (shape via ogr) also results in about the
> same warnings...
> > so next question: is there another

Re: [QGIS-Developer] Call for emergency 3.22 release

[Nyall Dawson via QGIS-Developer]

On Thu, 2 Feb 2023, 6:12 pm Alessandro Pasotti,  wrote:

> +1 for immediate release from me.
>
> On a side note (because I sympathize thinking about what I would feel
> if it was a commit of mine) : Julien is doing an amazing job, a
> mistake can happen to anyone.
>

100% agree - it could easily have been any of us leading to this.

I think the main lesson for us is "just" that we need to be extra careful
with backports to ltr, and carefully assess whether every backport is
really warranted or not.

Nyall

>
> On Thu, Feb 2, 2023 at 7:38 AM Andreas Neumann via QGIS-Developer
>  wrote:
> >
> > Hi Nyall,
> >
> > I agree, this is a pretty nasty one. Jürgen - can we release another
> release soon?
> >
> > Thank you Even for your reflections on the code patterns involved. I
> trust that the core devs will discuss and suggest improvements in our
> documentation/guidelines in order to avoid similar cases in the future.
> >
> > Thank you for your response.
> >
> > Andreas
> >
> > On 2023-02-02 02:19, Nyall Dawson via QGIS-Developer wrote:
> >
> > Hi PSC/list,
> >
> > I came across this horrible regression during bug hunting today:
> > https://github.com/qgis/QGIS/pull/51703
> >
> > If you load a project with any broken layers and then hover over the
> > layer in the layer tree, QGIS will instantly crash. It's a regression
> > caused by https://github.com/qgis/QGIS/pull/50256, and unfortunately
> > that PR was backported to 3.22 and accordingly the crash present in
> > the final release of 3.22.
> >
> > Given the extreme severity of this crash I believe we should be
> > pushing out another unplanned 3.22 patch release, as we cannot leave
> > the final 3.22 LTR with such a nasty regression in place.
> >
> > 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
>
>
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   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] Call for emergency 3.22 release

[Nyall Dawson via QGIS-Developer]

Hi PSC/list,

I came across this horrible regression during bug hunting today:
https://github.com/qgis/QGIS/pull/51703

If you load a project with any broken layers and then hover over the
layer in the layer tree, QGIS will instantly crash. It's a regression
caused by https://github.com/qgis/QGIS/pull/50256, and unfortunately
that PR was backported to 3.22 and accordingly the crash present in
the final release of 3.22.

Given the extreme severity of this crash I believe we should be
pushing out another unplanned 3.22 patch release, as we cannot leave
the final 3.22 LTR with such a nasty regression in place.

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] Debugging helpers in qt creator under python 3.11 -- solution

[Nyall Dawson via QGIS-Developer]

Hey list,

Just in case anyone else is running into this Qt Creator bug : on
systems with Python 3.11 current Qt Creator versions have broken
debugging helpers, which means you can't see the contents of
QString/QList/... (making QGIS debug much more painful then it should
be!)

The bug is described here:
https://bugreports.qt.io/browse/QTCREATORBUG-28659  , with a patch
included in this comment
https://bugreports.qt.io/browse/QTCREATORBUG-28659?focusedCommentId=702724&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-702724
which you can apply directly to your Qt Creator install to fix the
issue for now.

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] How to set defaults to QgsProcessingParameterMultipleLayers

[Nyall Dawson via QGIS-Developer]

On Sat, 28 Jan 2023 at 05:35, C Hamilton via QGIS-Developer
 wrote:
>
> I just received a request to update the Density Analysis plugin density hash 
> algorithms so they work with multiple layers and produce one density map 
> based off of multiple input layers. In the algorithm I have replaced 
> QgsProcessingParameterFeatureSource with QgsProcessingParameterMultipleLayers.
>
> Is there a way to automatically populate as default value of selected layers 
> in QgsProcessingParameterMultipleLayers with the selected layers or selected 
> groups of layers in the "Layer Panel"?  This would be incredibly useful.

You'd (unfortunately -- it's not a trivial change) need to do this via
a custom Processing widget wrapper, so that your parameter gets its
own widget class where you can implement this logic.

Nyall


>
> I am doing this as a QgsProcessingAlgorithm. The layerType to  
> QgsProcessingParameterMultipleLayers is QgsProcessing.TypeVectorPoint.
>
> Thanks for your help.
>
> Calvin
> ___
> QGIS-Developer mailing list
> QGIS-Developer@lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] Heads up: queued LTR branch now targets 3.28

[Nyall Dawson via QGIS-Developer]

Hi all,

Quick heads up: Given 3.22 is effectively EOL upstream, the queued LTR
fix branch on github now targets the 3.28 LTR release.

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