@fariza (Very) Dummy ideas about the text misalignement: could forcing a monospace font be of any help (but yes it is kind of a nuke...) or maybe have a lookax.table (I never used it so I am not sure how relevant it could be)?

@WeatherGod question mark in the toolbar? or as shortcut?

Using monospace as suggested (thanks@afvincent ), the alignment problem is gone

Before pressingf1

After pressingf1

Here is with the help icon

I think this is a great idea, but I'm a little confused byName(id) and theActive Toggle Tools header. I'm unsure if Name is the same as id and if there's a reason I need to know that, and I wonder if `Active Toggle Tools can be dropped since right underneath it says "Group" and "Active"-and what sort of group membership is that?

@story645 This tool is for the new toolmanager.
The printout is the same from the toolmanager example, that is why it has the active toggle tools, remember toggle tools can belong to a group where they are mutually exclusive (radio button), that is why it shows the current toggled tool for each group.
I will remove that group part as it is not really relevant to the "Help"

Removing the toggle groups and keymap before description

What are the "List" and "Show" tools that appear at the top?

@anntzer The screenshot is from the ToolManager example. That is why those two tools are there (that particular example custom tools)

That example should probably be updated to use another keymap than G, which is now used by default by grid_minor.

Edit: Also this kind of collision should probably be detected and trigger an error or at least a warning from toolmanager.

@anntzer the warning is in place from the begining.
If you run the exampleexamples/user_interfaces/toolmanager_sgskip.py

you will get a warning
workspace/matplotlib/lib/matplotlib/backend_managers.py:209: UserWarning: Key G changed from grid_minor to Show (k, self._keys[k], name))

It took me some time, but I decided to try to guess the number of characters per line (monospace) using the approx 60% (thanks for the tip).

Here is how it looks now, using this approach

Looks like the first column is too wide and the second one not wide enough? (the nav keys could definitely fit on a single line)

As a side note, the description for allnav and nav should be changed to "Enable" instead of "Enables",
and the inner caps in Toggle Fullscreen mode and Toggle Scale X/Y removed (for consistency with the other descriptions). There's also a typo Toogle -> Toggle (multiple times).

@anntzer I changed to a 6 column setup 1,2,3 widths so, the second is the double of the first and the third is half the total.
Nav keys don't fit into a sinlge line, but it is exceptionally long

few minor things, but LGTM otherwise.

Is there something left to do for this PR?

@anntzer@afvincent Is there something missing?

See#10851 (comment).

There might be another problem with this approach of adding an axes. I think if you happen to have setfig.set_tight_layout(True) and then enter help mode, it would trigger a warning about the axes not being compatible with tight_layout.

Not quite sure if it is generally a good idea to do this within the figure.

Advantage: Works for all backends.
Disadvantage: May mess up an existing plot.

Alternatives:

• Backend-native popup window. More work (i.e. per backend), but completely decoupled from the drawing logic.
• Compromise: Show this in a separate figure.

fwiw I am pretty strongly in favor of using backend-native stuff whenever possible (and yes, I know that@fariza thinks the opposite :-))...

Creating a separate figure is really easy if one can rely on using pyplot for that,

self.auxfig = pyplot.figure()# ....self.auxfig.show()

Would there be a reason for this not to be the case?

For the other proposal, maybe there should be a general pupose popup child window in the toolmanager which provides aset_text andget_figure method.
This could then be used by the helper tool, but equally by all any other tool that needs some window.
Of course it would need to be implemented by all backends and individual backends could implement further methods if needed.
Once such a window exists, the creation of new tools which need a separate figure or just some popup window would be really easy.

@ImportanceOfBeingErnest we don't want to use pyplot, that is something that we want removed somewhere in the future.

Not having read through the details of MEP27, but that seems to only target the plot window, not general purpose windows for displaying help.

I see two possible strategies:

• Either use this code but display it in a separate figure. For the time being, one can rely on pyplot for handling the backend-specific stuff for figure creation. Once MEP27 gets accepted, we can migrate the help from pyplot to the new API.
• Or, use the native widgetsHelp tool. #11045. As long as there is not more than the help window, that's fine in terms of complexity. If you want to do it for 10 different things, one will have to think about internal backend abstractions for simple general-purpose windows. I assume that you would want some interactive elements like buttons etc. as well, which is also not easy when drawing it all on a figure.

I tend to go with the native widgets.