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.

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

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

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
Copy link

github-actions bot commented Dec 12, 2024

🪟 Windows builds

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

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 40f5d51)

@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.

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
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 stale Uh oh! Seems this work is abandoned, and the PR is about to close.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants