ATLAS: LEGEND support clipping

[elpaso]

Fix #54654

Working on the tests...

@Geoscope19 please test the artifact when ready.

[Geoscope19]

I’m a new, I don’t understand what to do. Could you explain to me how to proceed?

[elpaso]

I’m a new, I don’t understand what to do. Could you explain to me how to proceed?

Sure, you couldn't possibly know, it is well hidden.

Download this package on windows, unzip it twice in a folder of your choice and run the qgis exe.

https://github.com/qgis/QGIS/suites/16418208318/artifacts/938243476

This is a QGIS build automatically created with the changes in this PR so you can test the changes.

[Geoscope19]

@elpaso Thank you.
Impeccable, the bug is fixed :-)

[elpaso]

@elpaso Thank you. Impeccable, the bug is fixed :-)

Thanks for checking!

[Geoscope19]

It is quite normal, it is you who are struggling to improve Qgis, it is rather for me to thank you for all the work

[troopa81]

I have to admit I'm no expert in this part of the code, sorry if I failed to understand the cause of some of this modifications.

[troopa81]

Suggested change

	layersToClip = mMap->atlasClippingSettings()->layersToClip();
	for ( QgsMapLayer *layer : std::as_const( layersToClip ) )
	const QList<QgsMapLayer *> layersToClip = mMap->atlasClippingSettings()->layersToClip();
	for ( QgsMapLayer *layer : layersToClip)

We can reduce the scope of layersToClip here

[elpaso]

Yes, the std::as_const should stay though even if it is redundant: I was told several times from other developers that it makes things clearer.

[elpaso]

Question: isn't my original version slightly faster? I don't know if the compiler can optimize it.

[troopa81]

Yes, we can keep the std::as_const indeed, it doesn't harm.

Not sure to understand why it would be slighly faster. Anyway it is purely cosmetic and non blocking for merge

[elpaso]

Yes, we can keep the std::as_const indeed, it doesn't harm.

Not sure to understand why it would be slighly faster. Anyway it is purely cosmetic and non blocking for merge

because the assignment down inside the loop is done multiple times instead of once before the loop.

[troopa81]

my comment was just to move the declaration at the same line of the assignment, not inside the loop. But nevermind that's not a big deal.

[qgis-bot]

The backport to queued_ltr_backports failed:

The process '/usr/bin/git' failed with exit code 1

stderr

error: could not apply d156fbabfc... ATLAS: LEGEND support clipping
hint: After resolving the conflicts, mark them with
hint: "git add/rm <pathspec>", then run
hint: "git cherry-pick --continue".
hint: You can instead skip this commit with "git cherry-pick --skip".
hint: To abort and get back to the state before "git cherry-pick",
hint: run "git cherry-pick --abort".

stdout

Auto-merging src/core/layout/qgslayoutitemlegend.cpp
CONFLICT (content): Merge conflict in src/core/layout/qgslayoutitemlegend.cpp

To backport manually, run these commands in your terminal:

# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add .worktrees/backport-queued_ltr_backports queued_ltr_backports
# Navigate to the new working tree
cd .worktrees/backport-queued_ltr_backports
# Create a new branch
git switch --create backport-54692-to-queued_ltr_backports
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick d156fbabfcdd5bf632f2643d933a507d6885f96b,bbfefcfc81ef81f70df5b2e8d7ca1c79395859f0
# Push it to GitHub
git push --set-upstream origin backport-54692-to-queued_ltr_backports
# Go back to the original working tree
cd ../..
# Delete the working tree
git worktree remove .worktrees/backport-queued_ltr_backports

Then, create a pull request where the base branch is queued_ltr_backports and the compare/head branch is backport-54692-to-queued_ltr_backports.