Add Last & Next zoom actions in layouts

[YoannQDQ]

• Fix Composer: Add "Zoom Last" and "Zoom Next" tools #22077
• Fix Add "zoom last" and "zoom next" buttons to layout navigation toolbar #58413

Description

Adapt QgsMapCanvas zoomToLastExtent / zoomToNextExtent to the QgsLayoutView.

[github-actions]

🪟 Windows builds ready!

Windows builds of this PR are available for testing here. Debug symbols for this build are available here.

(Built from commit dc9abb6)

[nyalldawson]

@YoannQDQ got a screencast or screenshot of this in action?

(It's great to see you back! 😁 🥳)

[YoannQDQ]

Done! Also fixed pan handling. By the way @nyalldawson I noticed I can no longer edit the label(s) on the issues I create. Could I maybe get the privilege back? Thanks.

[github-actions]

🪟 Windows builds

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

🪟 Windows Qt6 builds

Download Windows Qt6 builds of this PR for testing.
(Built from commit 0353c3f)

[nyalldawson]

This looks wrong -- won't a resize generally cause a different extent? (eg when resizing to a different aspect ratio).

[YoannQDQ]

Yes, but actually, the term extentChanged is a bit misleading. What matters is only the center coordinates and the transform, and those won't change if the view is resized.

The problem I had was calling zoomNext or zoomLast can make the scrollbar appear or disappear, which triggers a resizeEvent, creating zoom history wipe or loops.

Also, not sure what is the emit zoomLevelChanged(); purpose here ; should the cache really be invalidated when the view is resized? If not, we can just get rid off those three lines.

[nyalldawson]

The problem I had was calling zoomNext or zoomLast can make the scrollbar appear or disappear, which triggers a resizeEvent, creating zoom history wipe or loops.

I'd handle that by adding a timer in the code which adds an entry to the zoom history. If the last entry was added < say 1 second ago, then we ignore the new one (or even better, replace the previous one!). That would also help with the case of say zooming in using a mouse wheel + ctrl key, which will fire many zoom level changes in a rapid period of time.

Also, not sure what is the emit zoomLevelChanged(); purpose here ; should the cache really be invalidated when the view is resized? If not, we can just get rid off those three lines.

Yes, it should. It triggers re-updating layout items at the new zoom level, because otherwise we'd draw them in a pixelated resized version of their previous render.

[YoannQDQ]

I must be missing something, but I don't see how resizing the view impacts the zoom level.

In the capture above, resizing the view does not resize the content, so invalidating the map item cache seems to serve no purpose.

[nyalldawson]

You're right, sorry! We don't need the zoomElevelChanged signal there.

[nyalldawson]

Could all this logic be moved into the existing QgsLayoutView::viewChanged method? That should already be getting called whenever the view extent is changed, and already handles all the different ways this can happen.

That should also avoid the emit view()->extentChanged(); calls from other classes, which is rather fragile.

[YoannQDQ]

The problem is viewChanged is called every time the scrollbar moves. So dragging the scrollbar handle will trigger many MANY viewChanged calls, and we dont want them to clutter the zoom level history. Similarly, we do not want to add entries in the history while dragging the view with the pan tool.

[nyalldawson]

See above -- I'd handle this by using a timer to "collapse" extents which were used very close to each other.

[nyalldawson]

For bonus points you could handle Qt::BackButton and Qt::ForwardButton in QgsLayoutView::mouseReleaseEvent, just like we do in QgsMapCanvas. 🥳