Fix toolmanager x/y scale "togglers". #26580
Conversation
|
Yes, that's much better, thanks for the suggestion. |
|
I actually can't repro the failures locally (tests pass fine) :/ I'll investigate, but do you get them? |
|
Doc warnings are real:
I'm off-site and cannot run the tests locally right now. |
|
(I know about the doc failures, I just need to (pick a better base class name and) rerun sphinx with -Omissing_references_write_json=1) |
ToolXScale and ToolYScale actually *cannot* be implemented using ToolToggleBase because a single "toggle" flag cannot store the log/linear state of *multiple* axes at once (i.e. the behavior of pressing "l" becomes wrong as soon as there are multiple axes in a given figure). Instead these must be plain tools that inspect the actual scale on the axes before deciding what to do. In practice, the easiest is to again reuse the classic toolbar implementation, as is already done for ToolGrid and ToolMinorGrid. Factor out that "forward-to-classic-toolbar" implementation into a _ToolForwardingToClassicToolbar base class and use that whereever possible.
ToolXScale and ToolYScale actually cannot be implemented using ToolToggleBase because a single "toggle" flag cannot store the log/linear state of multiple axes at once (i.e. the behavior of pressing "l" becomes wrong as soon as there are multiple axes in a given figure). Instead these must be plain tools that inspect the actual scale on the axes before deciding what to do.
In practice, the easiest is to again reuse the classic toolbar implementation, as is already done for ToolGrid and ToolMinorGrid. Factor out that "forward-to-classic-toolbar" implementation into a _ToolForwardingToClassicToolbar base class and use that whereever possible.
As in #16823, providing strict backcompat seems too hard to be worth it.
PR summary
PR checklist