Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork7.9k
Unify toolbar init across backends.#22250
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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
... by instantiating classes specified by _toolbar2_class or_toolmanager_toolbar_class. (Third-parties can still manuallyinstantiate their toolbars the old-fashioned way.)Note that this would read a bit nicer if the toolbar classes weredefined before the manager classes, as this would allow _toolbar2_classand _toolmanager_toolbar_class to be set using normal class attributes,but moving large chunks of code around did not seem worth it. I onlydid so for the macosx backend, where the moved code is very little.This means that all toolbars default to having the standard tools added,not just the interactive ones. See e.g. changes intest_toolbar_zoompan: it is no longer necessary to explicitly registerall the tools (this actually now emits a duplicate tool warning).This also moves the canonical storage of the toolbar on wx from theframe to the manager (keeping a proxy for backcompat), for consistencywith the other backends.
| backend_tools.add_tools_to_container(self.toolbar) | ||
| if self.toolbar is not None: | ||
| self.SetToolBar(self.toolbar) | ||
| toolbar = self.canvas.manager.toolbar |
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.
Is that not?
| toolbar=self.canvas.manager.toolbar | |
| toolbar=self.figmgr.toolbar |
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.
Yes, but I have some later plans to get rid of the (non-standard) figmgr as well...
Uh oh!
There was an error while loading.Please reload this page.
... by instantiating classes specified by _toolbar2_class or
_toolmanager_toolbar_class. (Third-parties can still manually
instantiate their toolbars the old-fashioned way.)
Note that this would read a bit nicer if the toolbar classes were
defined before the manager classes, as this would allow _toolbar2_class
and _toolmanager_toolbar_class to be set using normal class attributes,
but moving large chunks of code around did not seem worth it. I only
did so for the macosx backend, where the moved code is very little.
This means that all toolbars default to having the standard tools added,
not just the interactive ones. See e.g. changes in
test_toolbar_zoompan: it is no longer necessary to explicitly register
all the tools (this actually now emits a duplicate tool warning).
This also moves the canonical storage of the toolbar on wx from the
frame to the manager (keeping a proxy for backcompat), for consistency
with the other backends.
PR Summary
PR Checklist
Tests and Styling
pytestpasses).flake8-docstringsand runflake8 --docstring-convention=all).Documentation
doc/users/next_whats_new/(follow instructions in README.rst there).doc/api/next_api_changes/(follow instructions in README.rst there).