[quick] Brand new elevation profile canvas item

[nirvn]

Description

This PR adds a brand new elevation profile canvas item to QGIS' quick toolbox. Here's how it looks in action:

The new item has a couple of properties to set things up including a project and a crs. When those properties are set, an invokable function, populateLayersFromProject(), is used to populate the item with layers from the project property. Then, the elevation profile canvas can be rendered by setting the profileCurve property (a QgsGeometry object). Et voila, you got a nice elevation profile using the provided project's symbology settings.

It's been tested for a couple of months in QField and has proven to be stable. Happy new year! :)

[nyalldawson]

@nirvn
any chance we can hold off on this one for a couple of days? I'm working now on the elevation profile chart item for layouts, and I strongly suspect I'll be adding some helper methods/classes as part of that which will simplify your new classes!

[nirvn]

@nyalldawson , sounds good.

[github-actions]

The QGIS project highly values your contribution and would love to see this work merged! Unfortunately this PR has not had any activity in the last 14 days and is being automatically marked as "stale". If you think this pull request should be merged, please check

• that all unit tests are passing

• that all comments by reviewers have been addressed

• that there is enough information for reviewers, in particular

  • link to any issues which this pull request fixes

  • add a description of workflows which this pull request fixes

  • add screenshots if applicable

• that you have written unit tests where possible
  In case you should have any uncertainty, please leave a comment and we will be happy to help you proceed with this pull request.
  If there is no further activity on this pull request, it will be closed in a week.

[nirvn]

Just courteously waiting ;)

[nirvn]

@wonder-sk , @PeterPetrik , I'll merge this later this afternoon if you guys don't plan to review it.

[wonder-sk]

@nirvn please feel free to merge...

(By the way, ~2 months ago we have dropped quickgui in Mergin Maps Input as a part of transition to CMake, as it was getting complicated to keep the machinery working to stay in sync with quickgui for the few files in the lib, and slowing down the development when some quickgui changes were necessary...)

[nirvn]

@wonder-sk , ok, good to know. Are you guys still trying to maintain that nice qgsquick overlap in the Venn diagram of QField & Input?

[wonder-sk]

Sorry the qgsquick files got blended into the rest of the Input app now...

[nirvn]

@wonder-sk , ouch; are you guys planning to upstream code from now on?

[nirvn]

@wonder-sk , beyond the question on upstreaming effort, I have to say this is a rather sad development. It feels like it was just yesterday that we had all agreed to commit to continue maintaining a reduced set of core classes across apps. Is there no way to reconsider this decision on Lutra’s part? The QgsQuickMapCanvas class for e.g. isn’t one that is bound to specific UI/UX, these foundational stones were never going to diverge from one project to another.

I also take note of the complete absence of acknowledgment/mention of the origin of the source code in the renamed classes (e.g. QgsQuickMapCanvas to InputMapCanvasMap), which isn’t a very polite move to do. While you guys can certainly fork away, it would be nice to maintain a form of acknowledgment of the QGIS community as the foundation of the classes being forked.

[wonder-sk]

@nirvn

are you guys planning to upstream code from now on?

I don't think there are going to be any upstream updates to quickgui from Lutra... unfortunately.

I have to say this is a rather sad development. It feels like it was just yesterday that we had all agreed to commit to continue maintaining a reduced set of core classes across apps.

It is sad for me too. I have done a lot of effort on trying to make QGIS Quick happen, to become another common QGIS library that other apps could use - and maybe one day eventually QGIS desktop app itself. But I was probably too naive - desktop QGIS does not seem anywhere close to adopting QML/Quick for its GUI (and in hindsight, that's probably good, as QML can be quite a mess). At Lutra I was always pushing to build this common library, even though that meant more hassle in the development. After the switch to the "slim" QGIS Quick library back in May 2021, it didn't really improve development workflow of our team - we still had to track changes to it in master, keep a more complicated build system and upstream our changes - all that for 9 moderately sized files. The team did not like to have this extra complexity for the little benefit, so when switching to CMake back in November, it was decided to drop this dependency and to make the life easier for our team...

I do not see much future for the QGIS Quick library anymore unfortunately - it turned out it was not working great for QField nor Input, and it never got any traction from any other party - so I am not sure if it is worth keeping it alive with further efforts. I admit it wasn't the best idea to start it in the first place...

And I am sorry we have not communicated that earlier, we should have, to avoid any surprises...

I also take note of the complete absence of acknowledgment/mention of the origin of the source code in the renamed classes (e.g. QgsQuickMapCanvas to InputMapCanvasMap), which isn’t a very polite move to do. While you guys can certainly fork away, it would be nice to maintain a form of acknowledgment of the QGIS community as the foundation of the classes being forked.

Apologies - this was definitely not meant as a bad intent, it only happened while making the headers use the same template as the other files without much extra thought. Peter has now brought the mentions back in MerginMaps/mobile#2540 - we definitely want to acknowledge QGIS community for the foundations!

[PeterPetrik]

Thank you Martin for expressing nicely what I feel. And it was definitely not meant with bad intent, and sorry if I offended someone by (lack) of communication.