From lova at kartoza.com Fri Oct 3 07:00:00 2025 From: lova at kartoza.com (Lova Andriarimalala) Date: Fri, 3 Oct 2025 17:00:00 +0300 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from September 08 to October 03, 2025 Message-ID: Hello everyone, Please find below some highlights regarding the development and maintenance of the QGIS Websites for the last two weeks, from September 08 to October 03, 2025 (*Note: I was on leave during the week of September 15*). *QGIS.org:* - Add automated content guidelines [New PR] - Fix wording for clarity in community guidelines section [New PR] - Add new user groups [New PR] - Add Volunteer Contributors list page [Updated PR] - Use slug when fetching members for more effective updates [Deployed] - Update patterns paper tests [Deployed] - Disallow downloads in robot.txt [Deployed] - Update macOS instructions [Deployed] - Add Privacy page and update menu structure [Deployed] - Refactor citation year handling and add yeartag shortcode [Deployed] *QGIS Hub:* - Add issue templates [New PR] - Use resend for email sending [Deployed] - Add support for alg decorator processing scripts [Deployed] - Refactor style handling to support multiple types [Deployed] - Contributors commit stats API [Deployed] *QGIS Feed:* - Add issue templates [New PR] - Use resend for email sending [New PR] *QGIS Plugins:* - Add support for multiple image attachments in feedback forms [Draft PR] - Use resend for email sending [Deployed] - Fix plugin updates errors [Deployed] - Use resend for email sending [Deployed] - Send plugin upload notifications to a specific group members only [Deployed] - Add a feature for version bulk delete [Deployed] - Block replace approved plugin version [Deployed] *QGIS Infrastructure:* - Script for automatic floating IP and DNS setup - Staging deployment test with Tim Have a nice weekend, Lova Andriarimalala *QGIS Full Stack Developer * *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrikl at gvc.gu.se Tue Oct 7 23:58:47 2025 From: fredrikl at gvc.gu.se (Fredrik Lindberg) Date: Wed, 8 Oct 2025 06:58:47 +0000 Subject: [QGIS-Developer] numpy version 2 Message-ID: Dear all, Are there any plans to implement numpy v2 in any near future as 1.26 is becoming rather old at this stage? best wishes, Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Wed Oct 8 04:54:07 2025 From: gdt at lexort.com (Greg Troxel) Date: Wed, 08 Oct 2025 07:54:07 -0400 Subject: [QGIS-Developer] numpy version 2 In-Reply-To: (Fredrik Lindberg via's message of "Wed, 8 Oct 2025 06:58:47 +0000") References: Message-ID: Fredrik Lindberg via QGIS-Developer writes: > Are there any plans to implement numpy v2 in any near future as 1.26 > is becoming rather old at this stage? Can you summarize what you found out when reading the build documentation about whether the qgis master branch can be built against numpy2, and what happened when you tried to build against it? >From numpy's release dates it looks like it is only roughly a year since it has been reasonable to use numpy in production. It's an interesting question how the numpy-using community views it, in terms of which is the first 2.x to be safe to use in production. From variablestarlight at gmail.com Wed Oct 8 05:18:24 2025 From: variablestarlight at gmail.com (=?UTF-8?Q?Hern=C3=A1n_De_Angelis?=) Date: Wed, 8 Oct 2025 14:18:24 +0200 Subject: [QGIS-Developer] numpy version 2 In-Reply-To: References: Message-ID: If it helps, I have been compiling the master branch regularly for sometime using numpy > 2 (currently 2.3.3, with python 3.13.7 on openSUSE Tumbleweed) without any apparent issue or malfunction that I have been aware of. I am not an expert on these matters though, and there may be issues that have escaped my attention. On Wed, Oct 8, 2025 at 1:54?PM Greg Troxel via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Fredrik Lindberg via QGIS-Developer > writes: > > > Are there any plans to implement numpy v2 in any near future as 1.26 > > is becoming rather old at this stage? > > Can you summarize what you found out when reading the build > documentation about whether the qgis master branch can be built against > numpy2, and what happened when you tried to build against it? > > From numpy's release dates it looks like it is only roughly a year since > it has been reasonable to use numpy in production. It's an interesting > question how the numpy-using community views it, in terms of which is > the first 2.x to be safe to use in production. > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrikl at gvc.gu.se Wed Oct 8 07:18:49 2025 From: fredrikl at gvc.gu.se (Fredrik Lindberg) Date: Wed, 8 Oct 2025 14:18:49 +0000 Subject: [QGIS-Developer] numpy version 2 In-Reply-To: References: Message-ID: I did not try to build nor have read the documentation, I have only started to experience conflicts in some of my plugins where third-party packages, started to require np>=2... ________________________________ Fr?n: QGIS-Developer f?r Greg Troxel via QGIS-Developer Skickat: den 8 oktober 2025 13:54 Till: Fredrik Lindberg via QGIS-Developer ?mne: Re: [QGIS-Developer] numpy version 2 Fredrik Lindberg via QGIS-Developer writes: > Are there any plans to implement numpy v2 in any near future as 1.26 > is becoming rather old at this stage? Can you summarize what you found out when reading the build documentation about whether the qgis master branch can be built against numpy2, and what happened when you tried to build against it? >From numpy's release dates it looks like it is only roughly a year since it has been reasonable to use numpy in production. It's an interesting question how the numpy-using community views it, in terms of which is the first 2.x to be safe to use in production. _______________________________________________ QGIS-Developer mailing list QGIS-Developer at lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From maplabs at light42.com Wed Oct 8 13:58:57 2025 From: maplabs at light42.com (Brian M Hamlin) Date: Wed, 8 Oct 2025 13:58:57 -0700 Subject: [QGIS-Developer] numpy version 2 In-Reply-To: References: Message-ID: for the python3 stack (large, complex)? #osgeolive has not made the switch to Numpy v2+ ? https://trac.osgeo.org/osgeolive/wiki/noblenightly57 --Brian M Hamlin??? /? MAPLABS? /? #osgeolive PSC On 10/8/25 04:54, Greg Troxel via QGIS-Developer wrote: > Fredrik Lindberg via QGIS-Developer > writes: > >> Are there any plans to implement numpy v2 in any near future as 1.26 >> is becoming rather old at this stage? > Can you summarize what you found out when reading the build > documentation about whether the qgis master branch can be built against > numpy2, and what happened when you tried to build against it? > > From numpy's release dates it looks like it is only roughly a year since > it has been reasonable to use numpy in production. It's an interesting > question how the numpy-using community views it, in terms of which is > the first 2.x to be safe to use in production. > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > From dvdkon at konarici.cz Thu Oct 9 01:29:10 2025 From: dvdkon at konarici.cz (=?UTF-8?B?RGF2aWQgS2/FiGHFmcOtaw==?=) Date: Thu, 9 Oct 2025 10:29:10 +0200 Subject: [QGIS-Developer] Progress on SIP incremental build grant Message-ID: <94d95f45-a586-4f85-99fb-b0fb9e2a8579@konarici.cz> Hi all, I'd like to share with you a report of the work I did on QEP 338 (SIP incremental builds): My original plan was to build each header file as a separate binding, then use SIP from a Python script, overriding a few methods to allow building just one binding out of a project. After a lot of effort, this plan sadly doesn't seem workable. PyQt's bindings aren't modularised enough, so building a single binding still needs to parse almost all of PyQt. Furthermore, SIP has a multi-stage parse-resolve-generate design, but the "parser" does more than just parse the code into an AST, not all references are resolved in the resolve phase, and imports are currently basically done by textual inclusion. I've tried making the necessary changes to SIP [1] and QGIS [2], but for the above reasons, I don't think the performance benefits for single-file builds are worth the added complexity and performance penalty for clean builds (which look to be over an hour currently). The good news is that with the knowledge from working on SIP, I've been able to improve the performance of regular clean builds, and those improvements might soon be merged into SIP itself [3]. I've also made some changes on the QGIS side to not rebuild unchanged code generated by SIP [4]. With code compilation now taking longer than SIP code generation, this effectively gives us incremental builds, just at a larger granularity. David Ko?a??k [1]: https://github.com/dvdkon/sip/tree/qgis-gb [2]: https://github.com/dvdkon/QGIS/tree/sip-incremental-build [3]: https://github.com/Python-SIP/sip/pull/87 [4]: https://github.com/qgis/QGIS/pull/63160 From julien.cabieces at oslandia.com Thu Oct 9 07:59:36 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Thu, 09 Oct 2025 16:59:36 +0200 Subject: [QGIS-Developer] New QEP: Customized Toolbars and Menus In-Reply-To: (Jacky Volpes via's message of "Wed, 25 Jun 2025 11:38:59 +0200") References: Message-ID: <87bjmgw27b.fsf@julienlaptop.home> Hi list, I have considerably updated the custom toolbars QEP and you have want to take a look at it. As part of this QEP, I propose to remove the "Widgets" customization part because it's probably never user, completely out of sync and very fragile. Please let me know if you think otherwise. Regards, Julien > Hi list! > > We propose to add a way to create custom toolbars and custom menus to QGIS. > > It will allow users to have their favorite tool buttons / menu items > grouped together in their own toolbars and menus. > > See https://github.com/qgis/QGIS-Enhancement-Proposals/pull/343 > > Best regards -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From apasotti at gmail.com Tue Oct 14 05:59:36 2025 From: apasotti at gmail.com (Alessandro Pasotti) Date: Tue, 14 Oct 2025 14:59:36 +0200 Subject: [QGIS-Developer] Github actions analysis Message-ID: Hi, During the last PSC meeting we talked briefly about how to solve the problem that we have with the Github CI limitations, one of the possible solutions that we discussed was to start migrating part of the CI to self-hosted runners. I've just made an attempt to understand the hardware requirements that we would need and I have collected some statistics from our Github account, summarized here for the period of the last 30 days: https://docs.google.com/spreadsheets/d/16-tiSLndm-ISxRFgZcE-Ewytr8cwLj00gdYs1iBsz58/edit?usp=sharing Considering that the standard public runner on Github runs on a 4 CPU + 16 GB RAM machine intel arch, the rough conclusion is that we would need 4.5 of these machines to handle the actual workload, please note that this a very rough estimation and does not take into account that we probably have peaking hours and we'd need more power if we don't want the jobs to sit in a queue for too long. Anyway, it's a start. Another thing to consider is that we could possibly cut some CI workflows (e.g. mingw64, is that useful?) or move some to a daily cronjob (ogc?). Any thoughts? -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From apasotti at gmail.com Tue Oct 14 06:06:05 2025 From: apasotti at gmail.com (Alessandro Pasotti) Date: Tue, 14 Oct 2025 15:06:05 +0200 Subject: [QGIS-Developer] Github actions analysis In-Reply-To: References: Message-ID: Sorry, in my previous email I wrote "we would need 4.5 of these machines" while I meant 3.5 machines. On Tue, Oct 14, 2025 at 2:59?PM Alessandro Pasotti wrote: > Hi, > > During the last PSC meeting we talked briefly about how to solve the > problem that we have with the Github CI limitations, one of the possible > solutions that we discussed was to start migrating part of the CI to > self-hosted runners. > > I've just made an attempt to understand the hardware requirements that we > would need and I have collected some statistics from our Github account, > summarized here for the period of the last 30 days: > > > https://docs.google.com/spreadsheets/d/16-tiSLndm-ISxRFgZcE-Ewytr8cwLj00gdYs1iBsz58/edit?usp=sharing > > Considering that the standard public runner on Github runs on a 4 CPU + 16 > GB RAM machine intel arch, the rough conclusion is that we would need 4.5 > of these machines to handle the actual workload, please note that this a > very rough estimation and does not take into account that we probably have > peaking hours and we'd need more power if we don't want the jobs to sit in > a queue for too long. > > Anyway, it's a start. > > Another thing to consider is that we could possibly cut some CI workflows > (e.g. mingw64, is that useful?) or move some to a daily cronjob (ogc?). > > Any thoughts? > > > -- > Alessandro Pasotti > QCooperative: www.qcooperative.net > ItOpen: www.itopen.it > -- Alessandro Pasotti QCooperative: www.qcooperative.net ItOpen: www.itopen.it -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cabieces at oslandia.com Tue Oct 14 06:27:22 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Tue, 14 Oct 2025 15:27:22 +0200 Subject: [QGIS-Developer] Github actions analysis In-Reply-To: (Alessandro Pasotti via's message of "Tue, 14 Oct 2025 14:59:36 +0200") References: Message-ID: <87bjm9txz9.fsf@julienlaptop.home> Hi, Thank you for this work > Considering that the standard public runner on Github runs on a 4 CPU + 16 GB RAM machine intel arch, the rough conclusion is that we would > need 4.5 Isn't it 3.5 instead ? That's the number you get in the table Assuming that we would have a better control on these machine, maybe we could have more disk space and so maybe more build cache that would speed up the build time. It could also reduce the time to pull some resource elsewhere (docker, oracle/hana binary...). It's highly hypothetical, I'm just wondering. Regards, Julien > Hi, > > During the last PSC meeting we talked briefly about how to solve the problem that we have with the Github CI limitations, one of the possible > solutions that we discussed was to start migrating part of the CI to self-hosted runners. > > I've just made an attempt to understand the hardware requirements that we would need and I have collected some statistics from our Github > account, summarized here for the period of the last 30 days: > > https://docs.google.com/spreadsheets/d/16-tiSLndm-ISxRFgZcE-Ewytr8cwLj00gdYs1iBsz58/edit?usp=sharing > > Considering that the standard public runner on Github runs on a 4 CPU + 16 GB RAM machine intel arch, the rough conclusion is that we would > need 4.5 of these machines to handle the actual workload, please note that this a very rough estimation and does not take into account that we > probably have peaking hours and we'd need more power if we don't want the jobs to sit in a queue for too long. > > Anyway, it's a start. > > Another thing to consider is that we could possibly cut some CI workflows (e.g. mingw64, is that useful?) or move some to a daily cronjob > (ogc?). > > Any thoughts? -- Julien Cabieces Senior Developer at Oslandia julien.cabieces at oslandia.com From gdt at lexort.com Tue Oct 14 06:39:31 2025 From: gdt at lexort.com (Greg Troxel) Date: Tue, 14 Oct 2025 09:39:31 -0400 Subject: [QGIS-Developer] Github actions analysis In-Reply-To: (Alessandro Pasotti via's message of "Tue, 14 Oct 2025 15:06:05 +0200") References: Message-ID: (psc dropped because it will bounce) As part of this, I think it would be good to consider how things might be different after a move from github to either codeberg or self-hosted forgejo. I don't mean to really design that, just a background thought of "if we (qgis.org) buy this hardware, and we later move, will we wish we had done something different, or will we just need more, and this will all be entirely usable, so it's fine". I suspect it really is fine. 16 GB sounds like low RAM for a CI machine for qgis. I would want to make sure it's expandable to at least 64G, and would start a bit higher. From matthias at opengis.ch Tue Oct 14 13:09:54 2025 From: matthias at opengis.ch (Matthias Kuhn) Date: Tue, 14 Oct 2025 22:09:54 +0200 Subject: [QGIS-Developer] Github actions analysis In-Reply-To: References: Message-ID: According to my understanding we don't have any pressure at the moment to move the build machines themselves, "just" to find a solution for the cache eviction. We could also use some cheap S3 storage as a drop in replacement with the risk that this is not as fast as the current github cache, but this would be easier to do than to deploy our own runners. ... however, if we want to move to self hosted runners, a few thoughts: - We will need multiple architectures (I assume at least windows x64, linux x64, macos arm64) - We will need to install the required dependencies (build tools etc) and manage the system images. I guess on linux that's straightforward with docker, not sure how this should be done on other platforms (some VMs?) - We will need to do the required system administration and maintenance For the vcpkg builds, I would appreciate having our own runners, as it would make the operating system and build tool updates more predictable. Right now, this happens every few weeks when github rolls out new runner images. Every time this happens all dependencies are rebuilt which takes a few hours (more than 6 hours which is the github runner limit). Such full rebuilds could be reduced. If we provision our own runners we should probably also get stronger ones than the free ones from github. Cheers Matthias On Tue, Oct 14, 2025 at 3:39?PM Greg Troxel via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > (psc dropped because it will bounce) > > As part of this, I think it would be good to consider how things might > be different after a move from github to either codeberg or self-hosted > forgejo. I don't mean to really design that, just a background thought > of "if we (qgis.org) buy this hardware, and we later move, will we wish > we had done something different, or will we just need more, and this > will all be entirely usable, so it's fine". I suspect it really is > fine. > > 16 GB sounds like low RAM for a CI machine for qgis. I would want to > make sure it's expandable to at least 64G, and would start a bit higher. > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.nijssen at terglobo.nl Thu Oct 16 04:22:48 2025 From: r.nijssen at terglobo.nl (Raymond Nijssen) Date: Thu, 16 Oct 2025 13:22:48 +0200 Subject: [QGIS-Developer] Execute SQL tool Message-ID: <9a8dc0e5-bf9f-4a1d-8538-13b2ff7d5d47@terglobo.nl> Dear devs, Lately I've been working with the Execute SQL tool on gpkg database files, cause I'm trying to switch from the DB Manager to the QGIS native tool. I was told the DB Manager is going to be deprecated in the near future. Is that the goal? I'm wondering if other people are using the 'Execute SQL' tool as well, as I'm not really satisfied with the current functionality and I cannot find any complains in the mailing list or github issues. Some problems I encounter: * The result table is (randomly?) not showing the FID or other PK columns, nor the geometry column. But those are often important while writing SQL queries. * Loading the QueryLayer always creates a multigeometry layer not showing anything on the map. (Btw I think QGIS should be able to render multigeometries, or at least to set a 'point', 'line' or 'polygon' style to the multigeometry layer to force it rendering that type.) * The cursor somehow jumps randomly to other lines when (re)focusing on the SQL S * The clear button works *very* well, when you accidentally press it you loose the entire query without warning and ctrl-Z won't bring it back. * The error widget is large and leaving only a few lines of the SQL editor to find an fix my error. The splitter between them does not show the handle for resizing the widgets. If developers are interested in fixing this, please let me know. I'm happy to help and test and I can also try finding some funding for this. For me, a more productive SQL tool in QGIS would be: * In a dockable panel * Connected to one or more layers that update every time I execute my SQL (like the map in DBeaver) QGIS could be the best geo SQL editor in the world! There are current issues: https://github.com/qgis/QGIS/issues?q=is%3Aissue%20state%3Aopen%20%27execute%20sql%27 Should I add all mine? Kind regards, Raymond From lnicola at dend.ro Thu Oct 16 22:00:22 2025 From: lnicola at dend.ro (=?UTF-8?Q?Lauren=C8=9Biu_Nicola?=) Date: Fri, 17 Oct 2025 08:00:22 +0300 Subject: [QGIS-Developer] numpy version 2 In-Reply-To: References: Message-ID: <6c549797-45f7-4666-ad9c-4513f719f0f3@betaapp.fastmail.com> Hi Fredrik, On Fedora 42 and 43, GDAL and QGIS use numpy 2. While https://github.com/qgis/QGIS/blob/master/INSTALL.md doesn't list it as a dependency, https://github.com/qgis/QGIS/blob/master/ChangeLog mentions in passing numpy 2 support. QGIS itself barely uses it, and GDAL has supported it for a long time, so you might as well give it a try. Laurentiu On Wed, Oct 8, 2025, at 09:58, Fredrik Lindberg via QGIS-Developer wrote: > Dear all, > Are there any plans to implement numpy v2 in any near future as 1.26 is becoming rather old at this stage? > > best wishes, > Fredrik > > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From apasotti at gmail.com Fri Oct 17 01:09:19 2025 From: apasotti at gmail.com (Alessandro Pasotti) Date: Fri, 17 Oct 2025 10:09:19 +0200 Subject: [QGIS-Developer] Execute SQL tool In-Reply-To: <9a8dc0e5-bf9f-4a1d-8538-13b2ff7d5d47@terglobo.nl> References: <9a8dc0e5-bf9f-4a1d-8538-13b2ff7d5d47@terglobo.nl> Message-ID: Hi Raymond, The long-term goal is still to replace the python implementation of DB manager with a C++ core implementation accessible from the browser, we are not there yet but significant steps in that direction have been made. Regarding your issues, I think the first step is to add your enhancement/bugfixing requests and specify when they are related to a specific provider (GPKG -> OGR). Please note that in the filtered list of existing issues there are a few unrelated ones (there is a processing algorithm with a similar name). Kind regards. On Thu, Oct 16, 2025 at 1:22?PM Raymond Nijssen via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Dear devs, > > Lately I've been working with the Execute SQL tool on gpkg database > files, cause I'm trying to switch from the DB Manager to the QGIS native > tool. I was told the DB Manager is going to be deprecated in the near > future. Is that the goal? > I'm wondering if other people are using the 'Execute SQL' tool as well, > as I'm not really satisfied with the current functionality and I cannot > find any complains in the mailing list or github issues. > > Some problems I encounter: > * The result table is (randomly?) not showing the FID or other PK > columns, nor the geometry column. But those are often important while > writing SQL queries. > * Loading the QueryLayer always creates a multigeometry layer not > showing anything on the map. (Btw I think QGIS should be able to render > multigeometries, or at least to set a 'point', 'line' or 'polygon' style > to the multigeometry layer to force it rendering that type.) > * The cursor somehow jumps randomly to other lines when (re)focusing on > the SQL S > * The clear button works *very* well, when you accidentally press it you > loose the entire query without warning and ctrl-Z won't bring it back. > * The error widget is large and leaving only a few lines of the SQL > editor to find an fix my error. The splitter between them does not show > the handle for resizing the widgets. > > If developers are interested in fixing this, please let me know. I'm > happy to help and test and I can also try finding some funding for this. > > For me, a more productive SQL tool in QGIS would be: > * In a dockable panel > * Connected to one or more layers that update every time I execute my > SQL (like the map in DBeaver) > > QGIS could be the best geo SQL editor in the world! > > There are current issues: > > https://github.com/qgis/QGIS/issues?q=is%3Aissue%20state%3Aopen%20%27execute%20sql%27 > > Should I add all mine? > > Kind regards, > Raymond > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From phidrho at gmail.com Fri Oct 17 02:55:14 2025 From: phidrho at gmail.com (=?UTF-8?Q?Vedran_Stojnovi=C4=87?=) Date: Fri, 17 Oct 2025 11:55:14 +0200 Subject: [QGIS-Developer] Execute SQL tool In-Reply-To: References: <9a8dc0e5-bf9f-4a1d-8538-13b2ff7d5d47@terglobo.nl> Message-ID: Hi Raymond and Alessandro, I would just like to add that I miss multiple SQL statements/SQL script execution in current implementation, and I've already created a feature request on this topic in GDAL/OGR: https://github.com/OSGeo/gdal/issues/11279 I think that these proposals are super useful features and I think that this is a good topic for QEP or for independent funding campain. pet, 17. lis 2025. u 10:09 Alessandro Pasotti via QGIS-Developer < qgis-developer at lists.osgeo.org> napisao je: > Hi Raymond, > > The long-term goal is still to replace the python implementation of DB > manager with a C++ core implementation accessible from the browser, we are > not there yet but significant steps in that direction have been made. > > Regarding your issues, I think the first step is to add your > enhancement/bugfixing requests and specify when they are related to a > specific provider (GPKG -> OGR). > > Please note that in the filtered list of existing issues there are a few > unrelated ones (there is a processing algorithm with a similar name). > > Kind regards. > > > > On Thu, Oct 16, 2025 at 1:22?PM Raymond Nijssen via QGIS-Developer < > qgis-developer at lists.osgeo.org> wrote: > >> Dear devs, >> >> Lately I've been working with the Execute SQL tool on gpkg database >> files, cause I'm trying to switch from the DB Manager to the QGIS native >> tool. I was told the DB Manager is going to be deprecated in the near >> future. Is that the goal? >> I'm wondering if other people are using the 'Execute SQL' tool as well, >> as I'm not really satisfied with the current functionality and I cannot >> find any complains in the mailing list or github issues. >> >> Some problems I encounter: >> * The result table is (randomly?) not showing the FID or other PK >> columns, nor the geometry column. But those are often important while >> writing SQL queries. >> * Loading the QueryLayer always creates a multigeometry layer not >> showing anything on the map. (Btw I think QGIS should be able to render >> multigeometries, or at least to set a 'point', 'line' or 'polygon' style >> to the multigeometry layer to force it rendering that type.) >> * The cursor somehow jumps randomly to other lines when (re)focusing on >> the SQL S >> * The clear button works *very* well, when you accidentally press it you >> loose the entire query without warning and ctrl-Z won't bring it back. >> * The error widget is large and leaving only a few lines of the SQL >> editor to find an fix my error. The splitter between them does not show >> the handle for resizing the widgets. >> >> If developers are interested in fixing this, please let me know. I'm >> happy to help and test and I can also try finding some funding for this. >> >> For me, a more productive SQL tool in QGIS would be: >> * In a dockable panel >> * Connected to one or more layers that update every time I execute my >> SQL (like the map in DBeaver) >> >> QGIS could be the best geo SQL editor in the world! >> >> There are current issues: >> >> https://github.com/qgis/QGIS/issues?q=is%3Aissue%20state%3Aopen%20%27execute%20sql%27 >> >> Should I add all mine? >> >> Kind regards, >> Raymond >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at 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 at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Srda?an pozdrav / Kind regards, Vedran Stojnovi?. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lova at kartoza.com Fri Oct 17 07:00:00 2025 From: lova at kartoza.com (Lova Andriarimalala) Date: Fri, 17 Oct 2025 17:00:00 +0300 Subject: [QGIS-Developer] QGIS Full Stack Developer Report from October 06 to October 17, 2025 Message-ID: Hello everyone, Please find below some highlights regarding the development and maintenance of the QGIS Websites for the last two weeks, from October 06 to October 17, 2025. *QGIS.org:* - Deploy i18n PR on https://staging.qgis.org - Add Payrexx donor update script [New PR] - Harvest Screenshots from the Hub [New PR] - Organise case studies and add dates to each one [Deployed] - Add new user groups [Deployed] *QGIS Hub:* - Review navigation menu in mobile [New PR] - Move theme to submodule [Deployed] - Add local setting management and update environment configuration [Deployed] - Refactor repository URL patterns [Deployed] - Filter bot commits and add avatar URL [Deployed] *QGIS Feed:* - Local settings override [Deployed] *QGIS Certification:* - Fix authentication UI [Deployed] *QGIS Infrastructure:* - Refactor infrastructure and host provisioning - Backup and restore scripts for Django hosts (feed, hub, plugins) Have a nice weekend! Best regards, Lova Andriarimalala *QGIS Full Stack Developer * *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From i at nstrokin.ru Sat Oct 18 01:59:07 2025 From: i at nstrokin.ru (=?utf-8?B?0J3QuNC60LjRgtCwINCh0YLRgNC+0LrQuNC9?=) Date: Sat, 18 Oct 2025 11:59:07 +0300 Subject: [QGIS-Developer] Is there a Python API to intercept point additions during geometry creation in QGIS? Message-ID: <942311760774823@mail.yandex.ru> An HTML attachment was scrubbed... URL: From dror.bogin at gmail.com Sat Oct 18 23:28:12 2025 From: dror.bogin at gmail.com (Dror Bogin) Date: Sun, 19 Oct 2025 09:28:12 +0300 Subject: [QGIS-Developer] Accessing bookmarks from the expression engine Message-ID: Hi all, I was asked last week about accessing project/user bookmarks from the expression engine and found it weird that it was missing. It sounded like a good idea for a plugin, but I found a way to make bookmarks accessible in a relatively easy way by adding the variable inside `QgsProject::createExpressionContextScope` (and adding the help string in `QgsExpression::buildVariableHelp`. Do I need to create a QEP for small changes like that or can I simply create a PR? -- Dror Bogin -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthias at opengis.ch Mon Oct 20 01:19:16 2025 From: matthias at opengis.ch (Matthias Kuhn) Date: Mon, 20 Oct 2025 10:19:16 +0200 Subject: [QGIS-Developer] Accessing bookmarks from the expression engine In-Reply-To: References: Message-ID: Hi, No need for a QEP for this, just open a PR. Cheers Matthias On Sun, Oct 19, 2025 at 8:28?AM Dror Bogin via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hi all, > > I was asked last week about accessing project/user bookmarks from the > expression engine and found it weird that it was missing. > It sounded like a good idea for a plugin, but I found a way to make > bookmarks accessible in a relatively easy way by adding the variable inside > `QgsProject::createExpressionContextScope` (and adding the help string in > `QgsExpression::buildVariableHelp`. > > Do I need to create a QEP for small changes like that or can I simply > create a PR? > > -- > Dror Bogin > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mehmet.duman at tubitak.gov.tr Wed Oct 22 01:01:04 2025 From: mehmet.duman at tubitak.gov.tr (Mehmet DUMAN (UZAY)) Date: Wed, 22 Oct 2025 11:01:04 +0300 (TRT) Subject: [QGIS-Developer] Request for Early Access or Contribution Opportunity for QGIS 4.0 Development Repository Message-ID: <735362186.488992.1761120064202.JavaMail.zimbra@tubitak.gov.tr> I hope this message finds you well. My name is Mehmet Duman, and I am currently working at T?B?TAK UZAY (The Space Technologies Research Institute of T?B?TAK) in Turkey. As part of my ongoing research and development efforts, I have been deeply involved in integrating QGIS into custom geospatial and remote sensing workflows, as well as building QGIS from source using Visual Studio and OSGeo4W environments. I recently learned about the upcoming QGIS 4.0 release, and I am very interested in contributing to or testing the early development version. I would like to kindly ask if there is any way to gain early access to the 4.0 development repository or participate in its testing or feedback process. If early access is restricted, I would still appreciate any guidance on how to stay updated on QGIS 4.0 development progress or join relevant discussions. Thank you very much for your time and for all your great work on QGIS. It is an invaluable project for both academic and professional communities. Kind regards, Mehmet Duman R&D Engineer ? T?B?TAK UZAY (The Space Technologies Research Institute) ? mehmet.duman at tubitak.gov.tr ? [ https://www.tubitak.gov.tr/ | www.tubitak.gov.tr ] -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreas at qgis.org Wed Oct 22 02:12:14 2025 From: andreas at qgis.org (Andreas Neumann) Date: Wed, 22 Oct 2025 11:12:14 +0200 Subject: [QGIS-Developer] Request for Early Access or Contribution Opportunity for QGIS 4.0 Development Repository In-Reply-To: <735362186.488992.1761120064202.JavaMail.zimbra@tubitak.gov.tr> References: <735362186.488992.1761120064202.JavaMail.zimbra@tubitak.gov.tr> Message-ID: Dear Mehmet, We are an Open Source project. This means that all of our source code is always publically available - no matter the stage of a release. There is no need to ask for early access. Just go to https://github.com/qgis/QGIS and use the master branch to create your own builds. If you want to use a ready to use installer from download.qgis.org just use the OSGeo4W installer and select QGIS 3.99 (qgis-qt6-dev-full). I believe there are also other methods to get hold of a current stage through Github artefacts. Hope this helps, Andreas On Wed, 22 Oct 2025 at 10:21, Mehmet DUMAN (UZAY) via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > I hope this message finds you well. > > > My name is Mehmet Duman, and I am currently working at T?B?TAK UZAY (The > Space Technologies Research Institute of T?B?TAK) in Turkey. As part of my > ongoing research and development efforts, I have been deeply involved in > integrating QGIS into custom geospatial and remote sensing workflows, as > well as building QGIS from source using Visual Studio and OSGeo4W > environments. > > I recently learned about the upcoming QGIS 4.0 release, and I am very > interested in contributing to or testing the early development version. I > would like to kindly ask if there is any way to gain early access to the > 4.0 development repository or participate in its testing or feedback > process. > > If early access is restricted, I would still appreciate any guidance on > how to stay updated on QGIS 4.0 development progress or join relevant > discussions. > > Thank you very much for your time and for all your great work on QGIS. It > is an invaluable project for both academic and professional communities. > > > Kind regards, > > > Mehmet Duman > R&D Engineer ? T?B?TAK UZAY (The Space Technologies Research Institute) > ? mehmet.duman at tubitak.gov.tr > ? www.tubitak.gov.tr > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -- -- Andreas Neumann QGIS.ORG board member (treasurer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From andreaerdna at libero.it Wed Oct 22 02:08:04 2025 From: andreaerdna at libero.it (Andrea Giudiceandrea) Date: Wed, 22 Oct 2025 11:08:04 +0200 Subject: [QGIS-Developer] Request for Early Access or Contribution Opportunity for QGIS 4.0 Development Repository Message-ID: <843cdc39-125a-4b8c-974c-c4386a3cbc9f@libero.it> Il 22/10/2025 10:01, Mehmet DUMAN (UZAY) via QGIS-Developer ha scritto: > I would like to kindly ask if there is any way to gain early access to > the 4.0 development repository Hi Mehmet, the upcoming QGIS 4.0 source code is publicly developed as 3.99.0-Master in the master branch of the QGIS repository on GitHub. Nightly development snapshot binaries are available for Windows via OSGeo4W network online installer as qgis-dev* and qgis-qt6-dev* packages and also as a weekly snapshot installers available at https://download.osgeo.org/qgis/windows/weekly/?C=M&O=D Binaries are also available for macOS https://github.com/opengisch/qgis-notarize and for Ubuntu/Debian Linux: see https://lists.osgeo.org/pipermail/qgis-developer/2025-July/067730.html, https://github.com/qgis/QGIS-Website/pull/731, https://github.com/qgis/QGIS-Website/issues/705, Regards. Andrea From dror.bogin at gmail.com Thu Oct 23 00:21:38 2025 From: dror.bogin at gmail.com (Dror Bogin) Date: Thu, 23 Oct 2025 10:21:38 +0300 Subject: [QGIS-Developer] Accessing bookmarks from the expression engine In-Reply-To: References:

Message-ID: Thank you for the response Matthias. I opened a PR - https://github.com/qgis/QGIS/pull/63613 , and it seems to have gone well, except 2 of the tests failed. I think one of the failures was due to the global AWS outage on Monday that caused some issues with docker hub, but the second one seems to be due to the PR suggesting changes to a core file ( src/core/project/qgsproject.cpp). Is there a way I can flag it as ok or should I just wait for a maintainer to get the time to check it? I am mostly bothered by the fact that the PR is marked with X as failing some tests and I don't think I can actually do anything differently right now. On Mon, 20 Oct 2025 at 11:19, Matthias Kuhn wrote: > Hi, > > No need for a QEP for this, just open a PR. > > Cheers > Matthias > > On Sun, Oct 19, 2025 at 8:28?AM Dror Bogin via QGIS-Developer < > qgis-developer at lists.osgeo.org> wrote: > >> Hi all, >> >> I was asked last week about accessing project/user bookmarks from the >> expression engine and found it weird that it was missing. >> It sounded like a good idea for a plugin, but I found a way to make >> bookmarks accessible in a relatively easy way by adding the variable inside >> `QgsProject::createExpressionContextScope` (and adding the help string in >> `QgsExpression::buildVariableHelp`. >> >> Do I need to create a QEP for small changes like that or can I simply >> create a PR? >> >> -- >> Dror Bogin >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From geraldo at servus.at Thu Oct 23 01:42:30 2025 From: geraldo at servus.at (Gerald Kogler) Date: Thu, 23 Oct 2025 10:42:30 +0200 Subject: [QGIS-Developer] qgis-qt6 Message-ID: Hi, I just saw that now there are official QGIS Qt6 builds for Debian 13 and Ubuntu 25.04 and 25.10 announced at [1] BUT I can't find qgis-qt6 packages neither in Debian nor Ubuntu, where can I get them from? Thanks Gerald [1] https://qgis.org/resources/installation-guide/#available-codenames From dvdkon at konarici.cz Thu Oct 23 02:35:15 2025 From: dvdkon at konarici.cz (=?UTF-8?B?RGF2aWQgS2/FiGHFmcOtaw==?=) Date: Thu, 23 Oct 2025 11:35:15 +0200 Subject: [QGIS-Developer] clang-tidy warning for narrowing to float Message-ID: Hi all, I'd like to propose a change to QGIS's clang-tidy settings. Currently, we have bugprone-narrowing-conversions [0] turned on by wildcard, which by default warns on converting between integer types, between floating point types, and from integers to floating points, if the full range of the source type won't fit into the destination type without loss of precision. I fully agree that conversions between different integer types should be conscious decisions, since they can lead to security issues [1]. I find the floating point warnings to have dubious usefulness, though. In QGIS' 3D code, we often need to use integer values (e.g. screen size) in floating point calculations, with practically no chance that the integer value won't be representable as a float, and zero risk even if it is - creating a security issue would require a very creative abuse of floats. Fixing the warning leads to a visual spam of static_cast()s everywhere, obscuring any actual bugs. Converting doubles to floats can actually cause issues, but it's also inevitable in many places, seeing as Qt3D uses floats, but we need to use doubles ourselves for precision reasons. Given this, I also think the warning isn't very useful here. I propose turning off WarnOnIntegerToFloatingPointNarrowingConversion and possibly WarnOnFloatingPointNarrowingConversion, based on your feedback. David Ko?a??k [1]: https://clang.llvm.org/extra/clang-tidy/checks/bugprone/narrowing-conversions.html [0]: e.g. char *copy_string(char *str, uint64_t str_size) { uint32_t size_plus_null = str_size + 1; char *copy = malloc(size_plus_null); memcpy(copy, str, str_size); copy[str_size] = '\0'; return copy; } From jef at norbit.de Thu Oct 23 05:23:06 2025 From: jef at norbit.de (=?utf-8?Q?J=C3=BCrgen_E=2E?= Fischer) Date: Thu, 23 Oct 2025 14:23:06 +0200 Subject: [QGIS-Developer] qgis-qt6 In-Reply-To: References: Message-ID: <20251023122306.ts7bwknyi3ozqoit@norbit.de> Moin Gerald, On Thu, 23. Oct 2025 at 10:42:30 +0200, Gerald Kogler via QGIS-Developer wrote: > BUT I can't find qgis-qt6 packages neither in Debian nor Ubuntu, where can I > get them from? https://qgis.org/debian-nightly 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: Pflichtangaben URL: From valentin.buira at gmail.com Fri Oct 24 02:52:58 2025 From: valentin.buira at gmail.com (Valentin Buira) Date: Fri, 24 Oct 2025 11:52:58 +0200 Subject: [QGIS-Developer] QEP 346: Port the model designer canvas from the Graphics View Framework to Qt Quick Message-ID: Hi all Thanks a lot for your feedback, insight( and warning! ) on the QEP[1]. I tailored the proposals based on it. And I am happy to say that the QEP is now ready to be submitted to vote by voting members. Kind regards, Valentin [1] https://github.com/qgis/QGIS-Enhancement-Proposals/pull/349 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ck29chaitanya at gmail.com Mon Oct 27 06:15:18 2025 From: ck29chaitanya at gmail.com (Chaitanya Kumar) Date: Mon, 27 Oct 2025 18:45:18 +0530 Subject: [QGIS-Developer] =?utf-8?q?Subject=3A_Need_guidance_on_building_?= =?utf-8?q?a_C++_QGIS_plugin_with_CMake_=E2=80=94_missing_QGISConfi?= =?utf-8?q?g=2Ecmake?= Message-ID: Dear QGIS Developers, I am currently trying to create a C++ plugin for QGIS using CMake on Windows, but I?m facing issues during the build process. When I configure my project with CMake, I receive the following error: > Could not find a package configuration file provided by "QGIS" with any of the following names: > QGISConfig.cmake > qgis-config.cmake > > Add the installation prefix of "QGIS" to CMAKE_PREFIX_PATH or set "QGIS_DIR" to a directory containing one of the above files. > If "QGIS" provides a separate development package or SDK, be sure it has been installed. I have installed QGIS 3.44.2 through the OSGeo4W Advanced Install option, and I?ve made sure to select and install the following packages: - qgis - qgis-deps - qgis-common - qgis-devel Since my plugin uses Qt, I?ve also installed: - qt5-devel - qt5-libs - qt5-tools - qt5-libs-symbols Despite this, I?m unable to locate the `QGISConfig.cmake` or `qgis-config.cmake` file in the installation directories (checked under `C:\OSGeo4W\apps\qgis\lib\cmake` and other subfolders). Additionally, while these packages were installed via OSGeo4W, I also noticed that **CMake itself is not available or detected in the environment**, even though it?s listed as an installable component. Could you please guide me on how to properly set up the build environment for a C++ QGIS plugin, and how to make CMake recognize the QGIS development files? If there is a specific way to enable or locate the `QGISConfig.cmake` file within the OSGeo4W setup, I would really appreciate your advice. Thank you very much for your time and assistance. Best regards, Mutukula Chaitanya Kumar Hyderabad, India -------------- next part -------------- An HTML attachment was scrubbed... URL: From valentin.buira at gmail.com Mon Oct 27 07:44:21 2025 From: valentin.buira at gmail.com (Valentin Buira) Date: Mon, 27 Oct 2025 15:44:21 +0100 Subject: [QGIS-Developer] QEP 346: Port the model designer canvas from the Graphics View Framework to Qt Quick In-Reply-To: References: Message-ID: Hi all, There is an update and a change of plan regarding the QEP to port the model designer canvas to Qt Quick. We (OPENGIS.ch) initially wanted to do the refactor to QML/Quick as part of other UX improvements with a mix of self funding and external funding. The feedback and the warning from the core contributors make sense. Especially given: * A greater introduction of QML in the code base * The risk involved in the proposal We are backing down from our initial proposal, and as the comments suggested, we agree this refactor deserves a proper POC before submitting it to the community as a QEP. So for now, let's cancel the vote and the QEP. We can have a second discussion about this once we have a more elaborate POC. Sorry for the rollercoaster in our communications. There was a series of bad timing, misunderstanding and over optimism. Best regards, Valentin Le ven. 24 oct. 2025 ? 11:52, Valentin Buira a ?crit : > Hi all > > Thanks a lot for your feedback, insight( and warning! ) on the QEP[1]. I > tailored the proposals based on it. > > And I am happy to say that the QEP is now ready to be submitted to vote by > voting members. > > Kind regards, > Valentin > > [1] https://github.com/qgis/QGIS-Enhancement-Proposals/pull/349 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cabieces at oslandia.com Tue Oct 28 01:09:48 2025 From: julien.cabieces at oslandia.com (Julien Cabieces) Date: Tue, 28 Oct 2025 09:09:48 +0100 Subject: [QGIS-Developer] clang-tidy warning for narrowing to float In-Reply-To: ("David =?utf-8?B?S2/FiGHFmcOtaw==?= via QGIS-Developer"'s message of "Thu, 23 Oct 2025 11:35:15 +0200") References: Message-ID: <87y0ovqwfn.fsf@julienlaptop.home> Hi, I totally get your point, and I already faced such a situation where I have to introduce (too) many static_cast<>. On the other side, I already faced a situation where the use of this warning would have prevented a real issue [0]. So, I'm not really in favor of your proposal because it would disable the warning for the whole codebase, on some situation where it could be relevant. Could we not instead: - introduce float getters/setters to have the conversion at only one place - just have some converted variable "const float fvar = static_cast( var )". I don't think it makes the code so difficult to read. Regards, Julien [0] https://github.com/qgis/QGIS/pull/50016 > Hi all, > I'd like to propose a change to QGIS's clang-tidy settings. Currently, > we have bugprone-narrowing-conversions [0] turned on by wildcard, > which by default warns on converting between integer types, between > floating point types, and from integers to floating points, if the > full range of the source type won't fit into the destination type > without loss of precision. > > I fully agree that conversions between different integer types should > be conscious decisions, since they can lead to security issues [1]. I > find the floating point warnings to have dubious usefulness, though. > > In QGIS' 3D code, we often need to use integer values (e.g. screen > size) in floating point calculations, with practically no chance that > the integer value won't be representable as a float, and zero risk > even if it is - creating a security issue would require a very > creative abuse of floats. Fixing the warning leads to a visual spam of > static_cast()s everywhere, obscuring any actual bugs. > > Converting doubles to floats can actually cause issues, but it's also > inevitable in many places, seeing as Qt3D uses floats, but we need to > use doubles ourselves for precision reasons. Given this, I also think > the warning isn't very useful here. > > I propose turning off WarnOnIntegerToFloatingPointNarrowingConversion > and possibly WarnOnFloatingPointNarrowingConversion, based on your > feedback. > > David Ko?a??k > > [1]: > https://clang.llvm.org/extra/clang-tidy/checks/bugprone/narrowing-conversions.html > [0]: e.g. char *copy_string(char *str, uint64_t str_size) { > uint32_t size_plus_null = str_size + 1; > char *copy = malloc(size_plus_null); > memcpy(copy, str, str_size); > copy[str_size] = '\0'; > return copy; > } > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at 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.cabieces at oslandia.com From dvdkon at konarici.cz Tue Oct 28 01:55:20 2025 From: dvdkon at konarici.cz (=?UTF-8?B?RGF2aWQgS2/FiGHFmcOtaw==?=) Date: Tue, 28 Oct 2025 09:55:20 +0100 Subject: [QGIS-Developer] clang-tidy warning for narrowing to float In-Reply-To: <87y0ovqwfn.fsf@julienlaptop.home> References: <87y0ovqwfn.fsf@julienlaptop.home> Message-ID: Hi, thanks for your input. We can, however, disable only some aspects of the warning, and the only ones I'd like to disable are warnings on floating point conversions. The PR you linked fixed a bug with an unwanted integer-to-integer conversion. I'm convinced something like this couldn't happen with float conversions, but feel free to send me counterexamples. David Ko?a??k On 10/28/25 09:09, Julien Cabieces via QGIS-Developer wrote: > > Hi, > > I totally get your point, and I already faced such a situation where I > have to introduce (too) many static_cast<>. On the other side, I already > faced a situation where the use of this warning would have prevented a > real issue [0]. > > So, I'm not really in favor of your proposal because it would disable > the warning for the whole codebase, on some situation where it could be relevant. Could we not instead: > - introduce float getters/setters to have the conversion at only one place > - just have some converted variable "const float fvar = > static_cast( var )". I don't think it makes the code so difficult > to read. > > Regards, > Julien > > > [0] https://github.com/qgis/QGIS/pull/50016 > > >> Hi all, >> I'd like to propose a change to QGIS's clang-tidy settings. Currently, >> we have bugprone-narrowing-conversions [0] turned on by wildcard, >> which by default warns on converting between integer types, between >> floating point types, and from integers to floating points, if the >> full range of the source type won't fit into the destination type >> without loss of precision. >> >> I fully agree that conversions between different integer types should >> be conscious decisions, since they can lead to security issues [1]. I >> find the floating point warnings to have dubious usefulness, though. >> >> In QGIS' 3D code, we often need to use integer values (e.g. screen >> size) in floating point calculations, with practically no chance that >> the integer value won't be representable as a float, and zero risk >> even if it is - creating a security issue would require a very >> creative abuse of floats. Fixing the warning leads to a visual spam of >> static_cast()s everywhere, obscuring any actual bugs. >> >> Converting doubles to floats can actually cause issues, but it's also >> inevitable in many places, seeing as Qt3D uses floats, but we need to >> use doubles ourselves for precision reasons. Given this, I also think >> the warning isn't very useful here. >> >> I propose turning off WarnOnIntegerToFloatingPointNarrowingConversion >> and possibly WarnOnFloatingPointNarrowingConversion, based on your >> feedback. >> >> David Ko?a??k >> >> [1]: >> https://clang.llvm.org/extra/clang-tidy/checks/bugprone/narrowing-conversions.html >> [0]: e.g. char *copy_string(char *str, uint64_t str_size) { >> uint32_t size_plus_null = str_size + 1; >> char *copy = malloc(size_plus_null); >> memcpy(copy, str, str_size); >> copy[str_size] = '\0'; >> return copy; >> } >> _______________________________________________ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > From delazj at gmail.com Tue Oct 28 02:38:46 2025 From: delazj at gmail.com (DelazJ) Date: Tue, 28 Oct 2025 10:38:46 +0100 Subject: [QGIS-Developer] Remove "Polygons must follow boundaries of layer ..." check in Geometry checker plugin? Message-ID: Hi Devs, In the "Geometry checker" core plugin, there is that option called "Polygons must follow boundaries of layer ...", of which a Processing alg "Polygons exceeding boundaries" was recently created. While testing the algorithm in order to properly document it, we came across weird results (also output by the geometry checker) that we are unable to explain/understand their coherence. Issues and discussion are availabel at https://github.com/qgis/QGIS/issues/63454 and https://github.com/qgis/QGIS-Documentation/pull/10314#issuecomment-3425649278 1/ Does anyone *KNOW* how this option is really supposed to check? and understand the logic behind the output? 2/ If there is agreement that this tool does not adress any real use case, is it something we want to keep in QGIS (in this state)? Looking forward to your replies. Regards, Harrissou -------------- next part -------------- An HTML attachment was scrubbed... URL: From delazj at gmail.com Tue Oct 28 05:36:02 2025 From: delazj at gmail.com (DelazJ) Date: Tue, 28 Oct 2025 13:36:02 +0100 Subject: [QGIS-Developer] Minimal version of supported Qt6 version in QGIS 3.99 Message-ID: Hi devs, The INSTALL.md instructions [0] in code repo mentions Qt 5.15.2 as minimal version of supported Qt. With the move to Qt6-only in QGIS 4, do you know what would be the minimal supported version, please? Thanks, Harrissou [0] https://github.com/qgis/QGIS/blob/master/INSTALL.md#2-overview -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mike.Elstermann at itc-halle.de Wed Oct 29 03:59:35 2025 From: Mike.Elstermann at itc-halle.de (Elstermann, Mike) Date: Wed, 29 Oct 2025 10:59:35 +0000 Subject: [QGIS-Developer] =?utf-8?q?Emergency_=E2=80=93_Accidentally_dele?= =?utf-8?q?ted_plugin_from_the_QGIS_plugin_repository=2C_can_it_be_restore?= =?utf-8?q?d=3F?= Message-ID: <648513B4-586C-4689-B045-092C833BCC1A@itc-halle.de> Hello everyone, I accidentally deleted my plugin ?GeoBasis_Loader?; I actually only wanted to delete one version. Is there any way to restore it? If so, who can I contact? Thanks & best regards, Mike Elstermann -------------- next part -------------- An HTML attachment was scrubbed... URL: From lova at kartoza.com Wed Oct 29 05:48:28 2025 From: lova at kartoza.com (Lova Andriarimalala) Date: Wed, 29 Oct 2025 15:48:28 +0300 Subject: [QGIS-Developer] =?utf-8?q?Emergency_=E2=80=93_Accidentally_dele?= =?utf-8?q?ted_plugin_from_the_QGIS_plugin_repository=2C_can_it_be_?= =?utf-8?q?restored=3F?= In-Reply-To: <648513B4-586C-4689-B045-092C833BCC1A@itc-halle.de> References: <648513B4-586C-4689-B045-092C833BCC1A@itc-halle.de> Message-ID: Dear Mike, Deleting a plugin is a permanent action that cannot be undone, as stated on the plugin deletion confirmation page. Indeed, from the administration side, it would probably require patching the live database with your plugin (including all relations such as versions, feedback...) from the previous backup, which is a complex and risky task. I would suggest re-uploading the plugin as a new one (without changing the name), with all versions if needed. Best regards, Lova Andriarimalala *QGIS Full Stack Developer * *T *: +27(0) 87 809 2702 *E *: lova at kartoza.com *W* : kartoza.com *This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you * *have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying* *of the contents is prohibited.* On Wed, 29 Oct 2025 at 14:14, Elstermann, Mike via QGIS-Developer < qgis-developer at lists.osgeo.org> wrote: > Hello everyone, > > > I accidentally deleted my plugin ?GeoBasis_Loader?; I actually only wanted > to delete one version. Is there any way to restore it? If so, who can I > contact? > > Thanks & best regards, Mike Elstermann > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mike.Elstermann at itc-halle.de Wed Oct 29 08:01:24 2025 From: Mike.Elstermann at itc-halle.de (Elstermann, Mike) Date: Wed, 29 Oct 2025 15:01:24 +0000 Subject: [QGIS-Developer] =?utf-8?b?W0VYVF0gIEVtZXJnZW5jeSDigJMgQWNjaWRl?= =?utf-8?q?ntally_deleted_plugin_from_the_QGIS_plugin_repository=2C_can_it?= =?utf-8?q?_be_restored=3F=5BAchtung_-_Absenderpr=C3=BCfung_fehlgeschlagen?= =?utf-8?q?=5D?= In-Reply-To: References: <648513B4-586C-4689-B045-092C833BCC1A@itc-halle.de> Message-ID: OMG, THANKS! Zimbogisgeek suggested I try Admire, saying he might be able to help. I'm praying to all the GIS gods that it works ;-) Admire, are you reading this and can you help? Best regards, Mike Elstermann Am 29.10.2025 um 13:48 schrieb Lova Andriarimalala : ACHTUNG: Diese E-Mail stammt von einem externen Absender (au?erhalb der SWH-Gruppe). Bitte h?chste Vorsicht mit Dateianh?ngen und Hyperlinks! Im Zweifelsfall wird empfohlen, den Absender (z.B. per Telefon) zu kontaktieren und die Echtheit der E-Mail zu pr?fen. Dear Mike, Deleting a plugin is a permanent action that cannot be undone, as stated on the plugin deletion confirmation page. Indeed, from the administration side, it would probably require patching the live database with your plugin (including all relations such as versions, feedback...) from the previous backup, which is a complex and risky task. I would suggest re-uploading the plugin as a new one (without changing the name), with all versions if needed. Best regards, Lova Andriarimalala QGIS Full Stack Developer T : +27(0) 87 809 2702 E : lova at kartoza.com W : kartoza.com [https://kartoza.com/files/KartozaEmailSignature.gif] This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error, please notify the sender immediately and delete it from your system. Unauthorised use, disclosure, or copying of the contents is prohibited. On Wed, 29 Oct 2025 at 14:14, Elstermann, Mike via QGIS-Developer > wrote: Hello everyone, I accidentally deleted my plugin ?GeoBasis_Loader?; I actually only wanted to delete one version. Is there any way to restore it? If so, who can I contact? Thanks & best regards, Mike Elstermann _______________________________________________ QGIS-Developer mailing list QGIS-Developer at lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From nyall.dawson at gmail.com Wed Oct 29 14:15:13 2025 From: nyall.dawson at gmail.com (Nyall Dawson) Date: Thu, 30 Oct 2025 07:15:13 +1000 Subject: [QGIS-Developer] Minimal version of supported Qt6 version in QGIS 3.99 In-Reply-To: References: Message-ID: On Tue, 28 Oct 2025 at 22:36, DelazJ via QGIS-Developer wrote: > > Hi devs, > The INSTALL.md instructions [0] in code repo mentions Qt 5.15.2 as minimal version of supported Qt. With the move to Qt6-only in QGIS 4, do you know what would be the minimal supported version, please? Officially it's 6.4 (see https://github.com/qgis/QGIS/blob/master/CMakeLists.txt#L578), but there'd be a ton of bugs in that version. I wouldn't suggest building with anything older than 6.9. Nyall > > Thanks, > Harrissou > > [0] https://github.com/qgis/QGIS/blob/master/INSTALL.md#2-overview > _______________________________________________ > QGIS-Developer mailing list > QGIS-Developer at lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer From delazj at gmail.com Fri Oct 31 07:31:56 2025 From: delazj at gmail.com (DelazJ) Date: Fri, 31 Oct 2025 15:31:56 +0100 Subject: [QGIS-Developer] Minimal version of supported Qt6 version in QGIS 3.99 In-Reply-To: References:

Message-ID: Hi, Thanks Nyall for the information (and the pointer). If QGIS seems unusable with the minimal supported Qt version, should we not raise that min value? I see that Debian, Ubuntu (and their derivatives?) latest versions come with Qt 6.8 LTS. QGIS users may encounter bugs due to their specific version or do you think the risk is highly mitigated? Harrissou Le 29 octobre 2025 22:15:13 GMT+01:00, Nyall Dawson a ?crit : > On Tue, 28 Oct 2025 at 22:36, DelazJ via QGIS-Developer > wrote: > >> >> Hi devs, >> The INSTALL.md instructions [0] in code repo mentions Qt 5.15.2 as minimal version of supported Qt. With the move to Qt6-only in QGIS 4, do you know what would be the minimal supported version, please? >> > > Officially it's 6.4 (see > https://github.com/qgis/QGIS/blob/master/CMakeLists.txt#L578), but > there'd be a ton of bugs in that version. I wouldn't suggest building > with anything older than 6.9. > > Nyall > > >> Thanks, >> Harrissou >> >> [0] https://github.com/qgis/QGIS/blob/master/INSTALL.md#2-overview >> ------------------------------ >> QGIS-Developer mailing list >> QGIS-Developer at lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gdt at lexort.com Fri Oct 31 08:29:18 2025 From: gdt at lexort.com (Greg Troxel) Date: Fri, 31 Oct 2025 11:29:18 -0400 Subject: [QGIS-Developer] Minimal version of supported Qt6 version in QGIS 3.99 In-Reply-To: (DelazJ via's message of "Fri, 31 Oct 2025 15:31:56 +0100") References:

Message-ID: DelazJ via QGIS-Developer writes: > Thanks Nyall for the information (and the pointer). > If QGIS seems unusable with the minimal supported Qt version, should we not > raise that min value? > I see that Debian, Ubuntu (and their derivatives?) latest versions come > with Qt 6.8 LTS. QGIS users may encounter bugs due to their specific > version or do you think the risk is highly mitigated? This is a messy question, but from a packaging viewpoint, it is best for things like QGIS to require recent versions only when QGIS really requires it, because of a used API that is not in older versions, and to be careful and restrained in raising it. Of course QGIS users may encounter bugs with old Qt, old kernels, old gdal, and everything else. Adopting that means that QGIS should require the most recent formal release of all dependencies, at all times. That's bonkers. Entirely separately from what QGIS needs to build are the issues that come with each Qt version. It's not QGIS's place to break compatibility with older ones. Everyone should make their own decision about which version of everything to run, and generally the right answer is the latest stable release, or for upstreams that aren't really stable, the latest micro release that's .1, meaning disqualifying x.y.0, or z.0.0). It's important to realize that any particular packaging system with an old release series might adopt bugfixes that resolve the trouble. Insisting on new versions because somebody might not have bugfixes is rude and causes unnecessary work. If 6.8 LTS is problematic (note that it's LTS, so presumably fixes are pulled up), then that's on Debian and Debian derivatives to address it. It's not a QGIS problem. If there are problems with some particular older QT versions, that are problems with QGIS only, and not generally recognized outside of the QGIS world, then it makes sense to have a comment in the release notes about this. I suspect that this isn't what's going on, and that it's just that QT6 is moving fast and you really want to be on the latest release. As always, the LTS concept is problematic. If someone wants to run old QT, they should be ok with old QGIS, is my take on the world. Or if their LTS company wants to do maintenance. But it's not ok for LTS users/companies to demand that upstreams accomodate LTS. (It is ok to ask for min versions to be about used APIs and to refrain from crossing into "you shouldn't choose that" judgement. It is of course ok to offer judgement and advice in a way that doesn't break the build!)