I guess we need to standardize on a name there, effectively saying "a module with a Foo global is a backend". I'm fine with calling that Backend, I just want to make sure we agree on the name.

OTOH, another approach (#18854) would be to move "everything" to the FigureCanvas class ("a module with a FigureCanvas global is a backend"). (Note, in particular, that this allows reusing the already preexisting inheritance relationship that exists between canvases.) Perhaps you can comment on that PR?

I like#18854 a lot better. It gives you a path to fromjust a Figure walk your way up to building it a sibling in whatever scheme of canvas / manager / show / etc the user has put together.

I had thought about attaching the Backend object toFigureCanvas an friends, but then you can not re-use the classes between backends. Going the otherway and putting all of the parts on theFigureCanvas means with minimal sub-classing you can associate a custom manager to a givenFigureCanvas.

Thinking a bit more about the toolbar discussion, I think having down-stream sub-class either the Manger or Toolbar classes is not a terrible pattern to suggest. We tend to think in terms of libraries and compos-ability (which makes sense given our interest in working at the library level!), but the cases where I have seen where there is significant toolbar customization have been domain specific applications (the buttons the added only made sense in avery narrow science context) where the lack of being able to compose with another packages modifications does not matter.

Closing in favor of#18854 where (as normal)@anntzer is a few steps ahead of me.