Repository navigation
twin axis panning / zooming should be toggleable #1502
Description
When #1501 was reported, my initial reaction was that sometimes that's exactly the behavior one would want, i.e. panning and zooming to only operate on one of the axes that are not shared.
Or another potential enhancement, for twinx, for example, to have the panning and zooming operate on the original axis when the action happens on one side of the full axes (say the left), and have them operate only on the secondary axes when clicking around on the right hand side.
Another extension of this would be the same thing but divided into three regions (with center action acting on both axes)
Activity
pelson commented on Nov 16, 2012
Thanks for clearing up the original issue report @ivanov . I wonder if we need to have both issues open? Is there something in one which is not covered by the other?
Cheers,
ivanov commented on Nov 17, 2012
I think both make sense. #1501 is a bug or wart of an inconsistency of pan/zoom behavior in axes created using twinx/twiny that originate from axes created using axes_grid1. I think it makes sense to have plt.twinx() calls be consistent with ax.twinx() calls, regardless of how ax was created. In other words, normally, axes created using twinx() behave in manner A, but in this special case of being created by axes_grid1, they behave in manner B. So that bug is about making sure that if there's just one behavior for all cases, that they should all be A.
This issue is about the possibility of creating a new feature where the pan/zoom behavior might be specified (for all cases) as being A, B, C, or D, where A is the default, but user can specify other possibilities.
Does that seem more clear now?
jozsag commented on Nov 18, 2012
Looking forward to these alternative behaviors.
petehuang commented on Dec 31, 2016
This issue hasn't been updated in a while. What's the latest? Is it still a priority?
github-actions commented on Feb 28, 2023
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
tacaswell commented on Feb 28, 2023
#22347 likely addresses this.
jozsag commented on Mar 2, 2023
github-actions commented on Mar 4, 2024
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
ivanov commented on Mar 6, 2024
For anyone following along, looks like that PR is continuing as #27148
github-actions commented on Mar 7, 2025
This issue has been marked "inactive" because it has been 365 days since the last comment. If this issue is still present in recent Matplotlib releases, or the feature request is still wanted, please leave a comment and this label will be removed. If there are no updates in another 30 days, this issue will be automatically closed, but you are free to re-open or create a new issue if needed. We value issue reports, and this procedure is meant to help us resurface and prioritize issues that have not been addressed yet, not make them disappear. Thanks for your help!
QuLogic commented on May 14, 2025
#27148 was merged for 3.9.0