Skip to content

Keyboard shortcuts work when toolbar not displayed #1830

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

Closed
wants to merge 1 commit into from
Closed

Keyboard shortcuts work when toolbar not displayed #1830

wants to merge 1 commit into from

Conversation

warrd
Copy link

@warrd warrd commented Mar 16, 2013

Following from issue #1829, I've implemented a fix for keyboard shortcuts when the toolbar is not displayed.

In the existing code, state/logic of pan/zoom tools are coupled to the existence of a toolbar, so I went for the easiest fix possible: keeping the toolbar but setting visibility to false when None is chosen in matplotlibrc.

So far it's only implemented in the Qt and GTK backends: I don't have the others so no way to test.

@efiring
Copy link
Member

efiring commented Mar 16, 2013

I haven't tried it out, but offhand, I don't like the approach taken. If I specify no toolbar, I really mean no toolbar, not just "don't draw it".

What might be needed is a refactoring to separate the actual functionality of zoom, pan, keypress-handling, etc. from the particular Toolbar user interface.

@warrd
Copy link
Author

warrd commented Mar 16, 2013

Yes, fair enough, I agree it's slightly hacky. I originally thought about a major refactor but it's my first time with the codebase, so wanted to make changes to application logic as minor as possible.

The refactor would have to involve moving a lot of the behaviour in NavigationToolbar2 to the main FigureCanvasBase, or more likely a new class that keeps track of cursor state etc.
What do you think?

@efiring
Copy link
Member

efiring commented Mar 16, 2013

Yes, it looks to me like most of the necessary functionality is already in NavigationToolbarBase, so that could be renamed (Navigation? Interaction? Control?) with the relatively small toolbar-specific parts moved into a ToolbarBase.

Or maybe there are really three components: plot manipulation state and actions, which are backend-independent; keypress-handling, which is backend-dependent; and the specific Toolbar interface, which is very backend dependent.

@dmcdougall
Copy link
Member

What might be needed is a refactoring to separate the actual functionality of zoom, pan, keypress-handling, etc. from the particular Toolbar user interface.

This gels well with the Model-View-Controller mentality in Apple's frameworks.

@warrd
Copy link
Author

warrd commented Mar 23, 2013

I'm closing this pull request and putting in a new one with a more significant refactor

@warrd
Copy link
Author

warrd commented Mar 23, 2013

See pull request #1849

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants