I haven't tried it out, but offhand, I don't like the approach taken. If I specify no toolbar, I really meanno 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.

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 inNavigationToolbar2 to the main FigureCanvasBase, or more likely a new class that keeps track of cursor state etc.
What do you think?

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.

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.

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

See pull request#1849