cc @pelson

Here's what it comes down to: we create a random div here.
If I instead force it to use the div created by the ipywidget, we get the initial draw, but then find_output_cell fails.

I see two options:

1. Modify FigureManagerNbAgg to accept an optional uuid and add some hackery to find_output_cell to handle the widget case.
2. Make the notebook backend always use a widget. We can still export a raw static display. See the QGrid widget I created for an example.

So long as on save you still get a static png I am in favor of option 2.

The future work on figure serialization + the future work on persistent widgets has a very nice synergy.

I'm in favour of option 2 too if we can pull it off. Is there anything I can help with, or have you got everything you need @blink1073?

@pelson, all I need is another 6 hours a day 😄

I know that feeling 😄

I also think the notebook backend should always use a widget.

@blink1073 did you see structure of ToolManager and the interaction with Tools (the result of MEP22)
Also, with MEP27 @OceanWolf is introducing a new architecture of FigureManager, Window, layout...
I say this because to finalize MEP22 and MEP27 we are going to be porting all the backends, and with this and all new development (backend related) it would be easier if it's compatible with the new structure of things.

I was only planning to attack the "which websocket" and "which div" part of the equation, at least to start.

Not sure if that will overlap, I haven't seen much of the code of NbAgg yet, only WebAgg which I rewrite a large part of including the websocket and div part... I did most of it, but it annoyed the heck out of me (having spent about 40 hours on it, where as the other backends only took around 4 or so), then it went on ice to concentrate on the main branch (GTK3) of MEP27. Imagine then I will do the easy TkAgg before resuming WebAgg and fix up NbAgg.