-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Add Last & Next zoom actions in layouts #58789
base: master
Are you sure you want to change the base?
Conversation
be685de
to
a6bf1bf
Compare
@YoannQDQ got a screencast or screenshot of this in action? (It's great to see you back! 😁 🥳) |
a6bf1bf
to
8f896a5
Compare
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. |
dc9abb6
to
bbbf7ce
Compare
🪟 Windows buildsDownload Windows builds of this PR for testing. 🪟 Windows Qt6 buildsDownload Windows Qt6 builds of this PR for testing. |
bbbf7ce
to
ec5b8ec
Compare
ec5b8ec
to
5184972
Compare
5184972
to
ff61225
Compare
ff61225
to
0192669
Compare
connect( this, &QgsLayoutView::zoomLevelChanged, this, &QgsLayoutView::extentChanged ); | ||
|
||
verticalScrollBar()->installEventFilter( this ); | ||
horizontalScrollBar()->installEventFilter( this ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See above -- I'd handle this by using a timer to "collapse" extents which were used very close to each other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any thoughts on this @YoannQDQ ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree that the approach you suggested is better (it could also be applied to the map canvas imho). There's some additional consideration in the layout view since changing the scale will sometime make the scalebars appears/disappear, which in turn slightly change the view center and does not play well with the zoom/center history. It is on my backlog, but I haven't had the time to finalize it yet.
For bonus points you could handle Qt::BackButton and Qt::ForwardButton in QgsLayoutView::mouseReleaseEvent, just like we do in QgsMapCanvas. 🥳 |
0192669
to
f1805b3
Compare
f1805b3
to
0353c3f
Compare
599af3e
to
2c41878
Compare
5e37b15
to
5edaaa6
Compare
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
|
5edaaa6
to
47f2a6a
Compare
Description
Adapt QgsMapCanvas zoomToLastExtent / zoomToNextExtent to the QgsLayoutView.