Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[elevation Profile] Correctly add a layer generated by a processing #59850

Merged
merged 2 commits into from
Feb 7, 2025
Merged

[elevation Profile] Correctly add a layer generated by a processing #59850

merged 2 commits into from
Feb 7, 2025

Conversation

ptitjano
Copy link
Contributor

Issue

This is somewhat similar to #59809

  1. Create a new project
  2. Open a new elevation profile
  3. Launch any processing to create a new Layer
  4. The new layer is not added to the elevation profile widget

Solution

This is because QgsLayerTreeRegistryBridge listens to the QgsProject::legendLayersAdded() signal in order to update the elevation profile tree view. However this signal is not triggered by the current logic in the Postprocessing.py.
This PR changes the behavior of Postprocessing.py. by triggering the QgsProject::legendLayersAdded() signal and removing the duplicated node in the tree view.

This seems like a bad solution but I'm not sure what the correct fix. Should QgsLayerTreeRegistryBridge listen to an other signal? Which one? Should Postprocessing.py be modified?
Any thoughts?

cc @Djedouas

@github-actions github-actions bot added this to the 3.42.0 milestone Dec 12, 2024
@ptitjano ptitjano self-assigned this Dec 12, 2024
@ptitjano ptitjano added Processing Relating to QGIS Processing framework or individual Processing algorithms Bug Either a bug report, or a bug fix. Let's hope for the latter! Profile tool labels Dec 12, 2024
@github-actions GitHub Actions
Copy link

github-actions bot commented Dec 12, 2024 •
edited
Loading

🪟 Windows builds

Download Windows builds of this PR for testing.
Debug symbols for this build are available here.
(Built from commit 9b0c1af)

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 9b0c1af)

@nyalldawson
Copy link
Collaborator

@ptitjano

This seems like a bad solution but I'm not sure what the correct fix.

Indeed 😆 (not to mention it's only a partial fix -- if the layers are being placed in a specific group then the fix won't work either).

It makes me nervous seeing a lot of changes to Postprocessing.py. This is quite a fragile file (with no unit tests at all!), and we usually get regressions whenever it's modified. (And unfortunately we can't port it to c++ for compile-time safety, because it relies on RenderingStyles and ProcessingConfig, which are currently python only).

Should QgsLayerTreeRegistryBridge listen to an other signal? Which one? Should Postprocessing.py be modified?

Maybe we could work around this by moving the logic postprocessing which adds the layers to the tree directly to QgsLayerTreeRegistryBridge. I.e this loop: https://github.com/qgis/QGIS/blob/master/python/plugins/processing/gui/Postprocessing.py#L280-L296

@ptitjano
Copy link
Contributor Author

Maybe we could work around this by moving the logic postprocessing which adds the layers to the tree directly to QgsLayerTreeRegistryBridge. I.e this loop: https://github.com/qgis/QGIS/blob/master/python/plugins/processing/gui/Postprocessing.py#L280-L296

Could you explain a little bit how this could be achieved please? I don't know how QgsLayerTreeRegistryBridge works and I can't find any example.

@github-actions GitHub Actions
Copy link

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.

@github-actions github-actions bot added the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Dec 31, 2024
@github-actions GitHub Actions
Copy link

github-actions bot commented Jan 7, 2025

While we hate to see this happen, this PR has been automatically closed because it has not had any activity in the last 21 days. If this pull request should be reconsidered, please follow the guidelines in the previous comment and reopen this pull request. Or, if you have any further questions, just ask! We love to help, and if there's anything the QGIS project can do to help push this PR forward please let us know how we can assist.

@github-actions github-actions bot closed this Jan 7, 2025
@ptitjano ptitjano reopened this Jan 7, 2025
@github-actions github-actions bot removed the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Jan 7, 2025
@github-actions GitHub Actions
Copy link

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.

@github-actions github-actions bot added the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Jan 22, 2025
@lbartoletti lbartoletti removed the stale Uh oh! Seems this work is abandoned, and the PR is about to close. label Jan 22, 2025
@ptitjano ptitjano changed the title [elevation Profile] Correcly add a layer generated by a processing [elevation Profile] Correctly add a layer generated by a processing Feb 4, 2025
@ptitjano ptitjano force-pushed the elevation-profile-processing branch from 40f5d51 to 935916c Compare February 4, 2025 16:05
@ptitjano ptitjano marked this pull request as draft February 4, 2025 21:10
@ptitjano ptitjano force-pushed the elevation-profile-processing branch from 935916c to f92107d Compare February 4, 2025 21:41
@ptitjano ptitjano marked this pull request as ready for review February 4, 2025 21:41
@ptitjano ptitjano force-pushed the elevation-profile-processing branch from f92107d to 2549ef6 Compare February 5, 2025 17:16
@ptitjano
qgslayertreeregistrybridge: Add a layerInsertionPoint getter
e106e06
@ptitjano
postprocessing: Use QgsLayerTreeRegistryBridge to add layers
9b0c1af 
When a profile tool is already opened, the output of a procssing is
not added to its layer tree. This is because it relies on a
`QgsLayerTreeRegistryBridge`. Indeed, `QgsLayerTreeRegistryBridge`
listens to the `QgsProject::legendLayersAdded()` signal in order to
update the elevation profile tree view. However this signal is not
triggered by the current logic in `Postprocessing.py`because
`QgsProject::addMaplayer` is called with `addToLegend` set to
False. Then, the layer is added to the tree by calling
`QgsLayerTreeGroup::insertChildNode`.

This issue is fixed by creating a
`QgsLayerTreeRegistryBridge::InsertionPoint` to set the insertion
point and then calling `QgsProject::addMaplayer` with `addToLegend`
set to True.
@ptitjano ptitjano force-pushed the elevation-profile-processing branch from 2549ef6 to 9b0c1af Compare February 6, 2025 14:35
@nyalldawson nyalldawson merged commit a46f3e9 into qgis:master Feb 7, 2025
31 checks passed
@qgis-bot qgis-bot mentioned this pull request Feb 7, 2025
Merged
nyalldawson added a commit to nyalldawson/QGIS that referenced this pull request Feb 12, 2025
@nyalldawson
[processing] Fix exception when algorithm has no output layers
c5e979c 
Fixes regression caused by qgis#59850
@nyalldawson nyalldawson mentioned this pull request Feb 12, 2025
Merged
nyalldawson added a commit to nyalldawson/QGIS that referenced this pull request Feb 12, 2025
@nyalldawson
[processing] Fix exception when algorithm has no output layers
0180380 
Fixes regression caused by qgis#59850
qgis-bot pushed a commit that referenced this pull request Feb 12, 2025
@nyalldawson @github-actions
[processing] Fix exception when algorithm has no output layers
ed43e7d 
Fixes regression caused by #59850
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@nyalldawson nyalldawson nyalldawson approved these changes

Assignees

@ptitjano ptitjano

Labels
backport release-3_40 Bug Either a bug report, or a bug fix. Let's hope for the latter! Processing Relating to QGIS Processing framework or individual Processing algorithms Profile tool
Projects
None yet
Milestone
3.42.0
Development

Successfully merging this pull request may close these issues.
3 participants
@ptitjano @nyalldawson @lbartoletti