[QGIS-Developer] Guidance on moving gui stuff to gui in QGIS

[Richard Duivenvoorde]

Hi Devs,

Do we have some guiding docs about the preferred/ideal (future) project/code 
structure of QGIS?

To be able to move some ui/gui components out of src/core to src/gui I got 
stuck because of my lack of C++ CMakeLists.txt knowledge [0]

But while moving around the ui and gui files I wondered if there was some 
shared idea of the project tree structure (espcially if this was documented 
somewhere).

Thinking about some docs answering questions like:
- should the code/dir/tree structure of the ui part of providers ideally mimick 
the providers tree? Like providers/foo/faa have it's ui stuff in gui/foo/faa
- should ui files be separated from it's accompanying gui h/cpp buddies? If 
not, again: should the tree structure mimic the src structure?
- remembering some discussion's about moving to a core and a gui lib, maybe 
move the ui part into gui?
- what would be the benefit of splitting up in core/gui?

I know these things are: never ideal, not easy to do, both practically and with 
dev's all have a different opinion about a 'proper project structure', but 
just asking :-)

Regards,

Richard Duivenvoorde

[0] https://github.com/qgis/QGIS/pull/44879#issuecomment-910988820

___
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] Nomination of Julien Cabieces for core committer status.

[Saber Razmjooei]

Hi Alessandro,

Apologies for hijacking the thread. Vincent Cloarec was nominated a while
back but the decision was never finalised (despite several positive votes
from other Devs).

>From what I understood the PSC was going to look into the nomination and
acceptance process. But the procedure was never finalised.

Kind regards
Saber

On Thu, 16 Sep 2021, 17:23 Alessandro Pasotti,  wrote:

> Hi PSC & QGIS devs,
>
> I'd like to formally nominate Julien Cabieces (@troopa81) for core
> committer status to QGIS.
>
> Julien has been doing excellent work in several areas of QGIS. His code is
> consistently of excellent quality and his knowledge in various aspects of
> QGIS are an extremely valuable asset to the project.
>
> His history of contributions also demonstrates a clear understanding of
> not only QGIS code practices, but also modern best-practice c++ and Qt
> development.
>
> I think it would be valuable to give Julien core commit rights and allow
> him with this also to enforce the pull request review team.
>
> Thanks for this consideration!
>
> Alessandro
>
> --
> 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-psc] Nomination of Julien Cabieces for core committer status.

[Régis Haubourg]

I also would give a huge +1 after those years working alongside with
Julien!
Julien is deeply committed in the project and will bring a nice Toulouse
accent in the upcoming hackfests 

Régis


Le jeu. 16 sept. 2021 à 17:23, Alessandro Pasotti  a
écrit :

> Hi PSC & QGIS devs,
>
> I'd like to formally nominate Julien Cabieces (@troopa81) for core
> committer status to QGIS.
>
> Julien has been doing excellent work in several areas of QGIS. His code is
> consistently of excellent quality and his knowledge in various aspects of
> QGIS are an extremely valuable asset to the project.
>
> His history of contributions also demonstrates a clear understanding of
> not only QGIS code practices, but also modern best-practice c++ and Qt
> development.
>
> I think it would be valuable to give Julien core commit rights and allow
> him with this also to enforce the pull request review team.
>
> Thanks for this consideration!
>
> Alessandro
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
> ___
> 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

[QGIS-Developer] Nomination of Julien Cabieces for core committer status.

[Alessandro Pasotti]

Hi PSC & QGIS devs,

I'd like to formally nominate Julien Cabieces (@troopa81) for core
committer status to QGIS.

Julien has been doing excellent work in several areas of QGIS. His code is
consistently of excellent quality and his knowledge in various aspects of
QGIS are an extremely valuable asset to the project.

His history of contributions also demonstrates a clear understanding of not
only QGIS code practices, but also modern best-practice c++ and Qt
development.

I think it would be valuable to give Julien core commit rights and allow
him with this also to enforce the pull request review team.

Thanks for this consideration!

Alessandro

-- 
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] network analyst in qgis

[Nils Nolde]

On 16.09.21 15:25, Greg Troxel wrote:

I am surprised it is considered ok to have non-free software as part of
a plugin.  Usually in Free Software plugins are considered derived works
of the project, so them including code not compatible with GPL2 seems
problematic.  I wasn't clear on the project's stance, but it seems to be
exactly this typical norm:

   https://blog.qgis.org/2016/05/29/licensing-requirements-for-qgis-plugins/
   
(I'm just a random user and packager, not speaking with any official

hats.)
The plugin is obviously FOSS & GPL, the routing engines & solvers and so 
on are BSD-2 and MIT. I'm not a lawyer, but I don't really see a problem 
_potentially_ having the bindings of the BSD-2 & MIT projects closed 
with attribution and include those as dependencies of a GPL software 
(plugin/QGIS). AFAIU GPL is important for consumer apps/libs, not the 
other way around. Happy to be proven wrong though, like I said the 
discussion is not settled yet.

___
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] network analyst in qgis

[Greg Troxel]

Nils Nolde  writes:

> It's mostly about making a self-contained plugin really. It's
> definitely not an option to have users install that stuff from source,
> there's thing like boost, protobuf etc involved and the very latest on
> Windows people will (rightfully) never even try. The Python bindings
> are pre-packaged as wheels, so installation becomes trivial. In that
> sense users could do it themselves potentially, but code can as well
> and I'd like that for UX. And my feeling is that the extra effort for
> automating that process is probably dwarfed compared to the tickets
> we'd get from users who don't manage to install things into OSGeo4W
> python.

Thanks, that is understandable, although I disagree about
"rightfully"

>>> I know it's strongly discouraged to submit binary components to the
>>> official plugin store. Also that wouldn't make much sense, some of
>>> those dependencies weigh like 30 MB or more (per platform). Can
>>> someone point us to a plugin that has a similar logic of pulling
>>> binary libs? I'd like to avoid to leave it to the user to install
>>> those dependencies, rather have it done automatically.
>> And 'per platform' is going to support only a handful of platforms,
>> compared to all the places where one can build qgis.

> Haha true! At least it's a manylinux distribution for linuxes with
> glibc 2.24 (didn't wanna go down the rabbit hole of earlier versions
> with that many dependencies). 3 distros (mac 10.9, win amd64,
> manylinux) would amount to well over 300 MB, of which only a third is
> relevant to a single platform.

And then there are other operating systems, including ones that
mainsteram qgis culture hasn't heard of -- so there really needs to be a
"you must first install X, Y and Z", even if there is pre-built versions
for popular systems.

>> It could be that I'm asking questions about the broader plugin
>> architecture and portability, more than your situation.

> I guess the consent is to trust binaries being executed on a user's
> machine (I figured that's the reason QGIS doesn't want it). To a

That would be my concern, but I'm on the paranoid side.

> lesser extent maybe size. Licenses will be mostly GPL, maybe some
> closed (only for the bindings and packaging, the underlying engine is
> FOSS), still an ongoing discussion.

I am surprised it is considered ok to have non-free software as part of
a plugin.  Usually in Free Software plugins are considered derived works
of the project, so them including code not compatible with GPL2 seems
problematic.  I wasn't clear on the project's stance, but it seems to be
exactly this typical norm:

  https://blog.qgis.org/2016/05/29/licensing-requirements-for-qgis-plugins/
  
(I'm just a random user and packager, not speaking with any official
hats.)


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Re: [QGIS-Developer] network analyst in qgis

[Nils Nolde]

On 16.09.21 14:59, Greg Troxel wrote:

Nils Nolde  writes:

That all sounds like great progress.

Thanks Greg:)


Speaking as a packager for systems that are somewhat unusual:


solvers, that's above our heads. For everything we need a performant
routing engine, so we have to include several third-party FOSS
projects for routing & solving, those dependencies are unfortunately
all binary. So after the (hopefully encouraging) announcement, my
question:

I do not understand how depending on Free Software projects maintained
by others leads to "binary dependencies".  Can these really not be built
from source?  Do you just mean "on the system that uses the plugin, a
bunch of other packages (and presumably their python bindings?) must be
installed?  Is this just about making a self-contained plugin for
Windows where expecting qgis users to manage other code is wishful
thinking?
It's mostly about making a self-contained plugin really. It's definitely 
not an option to have users install that stuff from source, there's 
thing like boost, protobuf etc involved and the very latest on Windows 
people will (rightfully) never even try. The Python bindings are 
pre-packaged as wheels, so installation becomes trivial. In that sense 
users could do it themselves potentially, but code can as well and I'd 
like that for UX. And my feeling is that the extra effort for automating 
that process is probably dwarfed compared to the tickets we'd get from 
users who don't manage to install things into OSGeo4W python.

I know it's strongly discouraged to submit binary components to the
official plugin store. Also that wouldn't make much sense, some of
those dependencies weigh like 30 MB or more (per platform). Can
someone point us to a plugin that has a similar logic of pulling
binary libs? I'd like to avoid to leave it to the user to install
those dependencies, rather have it done automatically.

And 'per platform' is going to support only a handful of platforms,
compared to all the places where one can build qgis.
Haha true! At least it's a manylinux distribution for linuxes with glibc 
> 2.24 (didn't wanna go down the rabbit hole of earlier versions with 
that many dependencies). 3 distros (mac 10.9, win amd64, manylinux) 
would amount to well over 300 MB, of which only a third is relevant to a 
single platform.



Are there other recommendations to handle this situation? I guess at
the very least the user should agree to download those binaries. Since
we have to download 4 different libraries, do you think the user
should consent to each one individually (the routing engines are
crucial, but location/allocation & VRP not really)?

Is the consent about license, about trusting the code with one's data
(since it runs in user context), about the space, or something else?

It could be that I'm asking questions about the broader plugin
architecture and portability, more than your situation.
I guess the consent is to trust binaries being executed on a user's 
machine (I figured that's the reason QGIS doesn't want it). To a lesser 
extent maybe size. Licenses will be mostly GPL, maybe some closed (only 
for the bindings and packaging, the underlying engine is FOSS), still an 
ongoing discussion.


Greg

___
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] network analyst in qgis

[Greg Troxel]

Nils Nolde  writes:

That all sounds like great progress.

Speaking as a packager for systems that are somewhat unusual:

> solvers, that's above our heads. For everything we need a performant
> routing engine, so we have to include several third-party FOSS
> projects for routing & solving, those dependencies are unfortunately
> all binary. So after the (hopefully encouraging) announcement, my
> question:

I do not understand how depending on Free Software projects maintained
by others leads to "binary dependencies".  Can these really not be built
from source?  Do you just mean "on the system that uses the plugin, a
bunch of other packages (and presumably their python bindings?) must be
installed?  Is this just about making a self-contained plugin for
Windows where expecting qgis users to manage other code is wishful
thinking?

> I know it's strongly discouraged to submit binary components to the
> official plugin store. Also that wouldn't make much sense, some of
> those dependencies weigh like 30 MB or more (per platform). Can
> someone point us to a plugin that has a similar logic of pulling
> binary libs? I'd like to avoid to leave it to the user to install
> those dependencies, rather have it done automatically.

And 'per platform' is going to support only a handful of platforms,
compared to all the places where one can build qgis.

> Are there other recommendations to handle this situation? I guess at
> the very least the user should agree to download those binaries. Since
> we have to download 4 different libraries, do you think the user
> should consent to each one individually (the routing engines are
> crucial, but location/allocation & VRP not really)?

Is the consent about license, about trusting the code with one's data
(since it runs in user context), about the space, or something else?

It could be that I'm asking questions about the broader plugin
architecture and portability, more than your situation.

Greg


signature.asc
Description: PGP signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

[QGIS-Developer] network analyst in qgis

[Nils Nolde]

Hi devs,

I'd have sort of an early announcement, but also a related question:

we're currently developing a proper network analyst toolkit as a plugin. 
We feel it's another important step to make ArcMap/Pro more redundant 
haha one can dream:)  In any case, the plan is to provide highly 
performant network analysis, such as complex VRP solvers, 
location/allocation, regular routing/isochrones/matrix etc, and all 
LOCAL, no remote API, no HTTP (though optionally we provide HTTP 
capabilities for the routing engines). We really do aim to replace 
ESRI's network analyst in QGIS mid-term, though location/allocation 
features will be fairly slow for now as that is currently implemented in 
python (which we'll release as a PyPI packages as well). If there's 
enough traction we'd contract someone for proper c++ metaheuristic 
solvers, that's above our heads. For everything we need a performant 
routing engine, so we have to include several third-party FOSS projects 
for routing & solving, those dependencies are unfortunately all binary. 
So after the (hopefully encouraging) announcement, my question:


I know it's strongly discouraged to submit binary components to the 
official plugin store. Also that wouldn't make much sense, some of those 
dependencies weigh like 30 MB or more (per platform). Can someone point 
us to a plugin that has a similar logic of pulling binary libs? I'd like 
to avoid to leave it to the user to install those dependencies, rather 
have it done automatically.


Are there other recommendations to handle this situation? I guess at the 
very least the user should agree to download those binaries. Since we 
have to download 4 different libraries, do you think the user should 
consent to each one individually (the routing engines are crucial, but 
location/allocation & VRP not really)?


Really, really excited to see how this turns out!!:) ETA is end of 2021 
(so really early/mid-2022 probably;)).


All the best
Nils

___
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] Plugin Developers Who Don't Want to Add Capabilities - Go2NextFeature

[Raymond Nijssen]

What about adding just 1 line to the plugin, for firing a signal that 
you can catch in another plugin/tool that will take the snapshot? They 
might agree on that, cause nobody will notice it.


Raymond


On 16-09-2021 09:32, Johannes Kröger wrote:

Hi Calvin,

Looking at the list of issues I do not see any behaviour from the 
maintainer that shows a necessity for a fork. And there is just one user 
who asked for a snapshop feature, in two separate issues, one not even 
with a title.


Have you tried making a full description of the new feature and how it 
will integrate nicely and why the feature fits the scope of the project, 
followed by a well tested pull request with the new feature?


There are some unanswered merge requests but no visible repeated 
attempts to get the maintainer's attention. I'd try that first.


Making snapshops of the canvas sounds like a feature that has little to 
do with iterating through features. Maybe you are best served with 
another tiny plugin that does just that?


Cheers, Hannes

Am 15.09.21 um 14:47 schrieb C Hamilton:
I am faced with somewhat of a delima. This QGIS plugin is used by some 
of our analysts.


https://plugins.qgis.org/plugins/Go2NextFeature3/ 



Those analysts would like some additional features including automatic 
snapshoting of the canvas and saving it as an image for each feature. 
Something like this has been asked for by other users of the plugin 
over 2 years ago. See the issues.


https://gitlab.com/albertodeluca/go2nextfeature/-/analytics/issues_analytics 



In the comments of "Future of Plugin" the developers have made it 
clear that they want to keep the plugin simple. Probably because of 
this policy I see that someone else created a Go2NextFeaturePlus 
geared for OSM work and it is labeled as experimental.


I don't like replicating capability, but given that a plugin developer 
is unwilling to make any significant changes, how do you feel about 
another similar plugin be developed that has the additional capability 
that we need. I am not sure how to handle this situation. I don't 
think it would take much time to create a new plugin to do this with 
the expanded capabilities.


Thanks for your thoughts.

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


--
Johannes Kröger / GIS-Entwickler/-Berater
WhereGroup GmbH
Eifelstraße 7
53119 Bonn
Germany

Fon: +49 (0)228 / 90 90 38 - 36
Fax: +49 (0)228 / 90 90 38 - 11

johannes.kroe...@wheregroup.com
www.wheregroup.com
Geschäftsführer:
Olaf Knopp, Peter Stamm
Amtsgericht Bonn, HRB 9885
---

-
Schon gewusst?
In unserem Blog geben wir Tipps & Tricks zu
Open-Source-GIS-Software und berichten aus unserem Experten-Alltag:
https://wheregroup.com/blog/
-


___
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] Plugin Developers Who Don't Want to Add Capabilities - Go2NextFeature

[Johannes Kröger]

Hi Calvin,

Looking at the list of issues I do not see any behaviour from the 
maintainer that shows a necessity for a fork. And there is just one user 
who asked for a snapshop feature, in two separate issues, one not even 
with a title.


Have you tried making a full description of the new feature and how it 
will integrate nicely and why the feature fits the scope of the project, 
followed by a well tested pull request with the new feature?


There are some unanswered merge requests but no visible repeated 
attempts to get the maintainer's attention. I'd try that first.


Making snapshops of the canvas sounds like a feature that has little to 
do with iterating through features. Maybe you are best served with 
another tiny plugin that does just that?


Cheers, Hannes

Am 15.09.21 um 14:47 schrieb C Hamilton:
I am faced with somewhat of a delima. This QGIS plugin is used by some 
of our analysts.


https://plugins.qgis.org/plugins/Go2NextFeature3/ 



Those analysts would like some additional features including automatic 
snapshoting of the canvas and saving it as an image for each feature. 
Something like this has been asked for by other users of the plugin 
over 2 years ago. See the issues.


https://gitlab.com/albertodeluca/go2nextfeature/-/analytics/issues_analytics 



In the comments of "Future of Plugin" the developers have made it 
clear that they want to keep the plugin simple. Probably because of 
this policy I see that someone else created a Go2NextFeaturePlus 
geared for OSM work and it is labeled as experimental.


I don't like replicating capability, but given that a plugin developer 
is unwilling to make any significant changes, how do you feel about 
another similar plugin be developed that has the additional capability 
that we need. I am not sure how to handle this situation. I don't 
think it would take much time to create a new plugin to do this with 
the expanded capabilities.


Thanks for your thoughts.

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


--
Johannes Kröger / GIS-Entwickler/-Berater
WhereGroup GmbH
Eifelstraße 7
53119 Bonn
Germany

Fon: +49 (0)228 / 90 90 38 - 36
Fax: +49 (0)228 / 90 90 38 - 11

johannes.kroe...@wheregroup.com
www.wheregroup.com
Geschäftsführer:
Olaf Knopp, Peter Stamm
Amtsgericht Bonn, HRB 9885
---

-
Schon gewusst?
In unserem Blog geben wir Tipps & Tricks zu
Open-Source-GIS-Software und berichten aus unserem Experten-Alltag:
https://wheregroup.com/blog/
-



OpenPGP_0xBF7B268A77C202D5.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
QGIS-Developer mailing list
QGIS-Developer@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer