Why don't you merge this into MEP27 main PR?

Actually here there is a small problem (bug in MEP22 also) the user might want

• MEP27 + toolmanager + toolbar
• MEP27 + toolmanager
• MEP27
• Old stuff

I leave this unmerged for now just so that if I get additional feedback to change things with MEP27, then Travis will still report bugs, Travis doesn't have the rcParam set for toolmanager so it won't go down that codepath (I guess we could always add an additional Travis build in the test suite with the rcParam set though, perhaps a better option).

MEP27 + toolmanager without toolbar ain't really a bug, but a lack of a feature, but yes good catch. Do we want to add in that extra option? If so how would we do it?

I was thinking in playing with rcParams['backend'] or something like that.

Ahh, I think I have found a mistake in your thing above, item 3, just MEPP27 does not exist, it will always have the toolmanger.

How about rcParams['toolmanager'] == True/False to control whether we use MEP27 + ToolManager or not, and rcParams['toolbar'] == 'toolbar2' to control whether we show a toolbar or not... i.e. we loose the toolmanager option from rcParams['toolbar']. I think that makes more sense as we ensure the rcParams stay independent of each other i.e. specifying to use the new toolbar without the toolmanager won't work and will just give you the pure old stuff...

Why MEP27 can't exist without the toolmanager?
I am not comfortable with adding an additional rcParams key.
What about

• rcParams['toolbar'] == 'hidden' -> MEP27 + toolmanager
• rcParams['toolbar'] == 'toolmanager' -> MEP27 + toolmanager + toolbar
• rcParams['toolbar'] == 'False' -> MEP27

After deprecation time, we remove the other possibilities and we have only the 3 new states

Because the toolmanager always gets created. In the MEP22 PR we had:

if rcParams['toolbar'] != 'toolbar2':
  toolmanager = ToolManager(self.canvas)

Now with MEP27 we have decided that as we create completely new classes and will protect it with an rcParam, then we don't need to support the old toolbar from MEP27. Because of this a ToolManagerwill always get created with MEP27.

I don't get what your keyword of hidden will accomplish. Without the toolbar, the toolmanager just handles the keyboard shortcuts... so if we go with turning toolmanager off as well we just have no user interaction at all, apart from whatever the backend gives (maximize/minimize buttons etcetera)

Yes. In the past there was a discussion about exactly that. The most common case is the whole thing. But the conclusion was that the user has to be able to deactivate things one by one. That's why I said there was a bug in MEP22 in this moment is impossible not to have neither the old toolbar nor toolmanager

Okay, but what got decided in that discussion? As it made it into master I presumed that we didn't need it and could see (convinced myself of) the logic behind it that while visually the user might not want a toolbar, especially if they embed it in larger app, they would still want the keys bound to the window. But meh, personally I don't mind, and I will go with with whatever got decided.

The only thing I find odd lies in the naming of the rcParam, I thought about doing a trinary choice like you show above, but disregarded it as while before rcParams['toolbar'] == 'toolmanager': says to me "use the toolbar that interfaces with the toolmanager, which gets loaded by default unless we use the old toolbar. Now we extend the discussion out of the toolbar and into the toolmanager itself, so the naming of the rcParam doesn't feel right, hence my suggestion above to split into saying you want to using the toolmanager (and MEP27) and saying you want a toolbar.

Now toying with the idea of creating a group of rcParams like:

• tools.toolbar =
• tools...

Part of me also says do we need an option for just MEP27 just now? As such an option won't exist for long because it will soon (in a couple of releases time) we won't have any option to not use it...

Ok, I agree, for the moment we don't need such an option.
We can leave it as

• rcParams['toolbar']='toolmanager' -> MEP27 + toolmanager + toolbar
• rcParams['toolbar']='None' -> MEP27 + toolmanager

In any case this can be changed afterwards without having to modify every backend, only the pyplot and FigureManager stuff.

One problem there though, rcParams['toolbar']='None' already exists as an option for old stuff without toolbar...

Yep....
Ok, so for now we concentrate only on the option MEP27 + toolmanager + toolbar and when we clear this out, and everybody agrees we can move to introducing new keys.

Okay, but thinking about it a bit more, ToolManager without toolbar just replaces the key_press_handler, which we had no control over starting, so not having an rcParam(s) to mean MEP27 without ToolManager nor Toolbar feels like a potential missing feature rather than a bug.

Yes, I agree, leave it like that, and we'll work the possible rcParams later on

Something else for us to consider later, do we want to use a separate rcParam to control the statusbar?

I don't think we should go to that level of granularity. toolbar = toolbar + statusbar

What is holding you to merge this?

Only other possible comments that require me to change stuff in the main branch... I worry that I will get a comment that will require a huge change that I would want Travis to check... perhaps I worry too much...