You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here's what it comes down to: we create a random divhere.
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:
Modify FigureManagerNbAgg to accept an optional uuid and add some hackery to find_output_cell to handle the widget case.
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.
@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.
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.
Activity
blink1073 commentedon Jul 4, 2015
cc @pelson
blink1073 commentedon Aug 30, 2015
Here's what it comes down to: we create a random
divhere.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:
FigureManagerNbAggto accept an optional uuid and add some hackery tofind_output_cellto handle the widget case.tacaswell commentedon Aug 30, 2015
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.
pelson commentedon Sep 3, 2015
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?
blink1073 commentedon Sep 3, 2015
@pelson, all I need is another 6 hours a day 😄
pelson commentedon Sep 3, 2015
I know that feeling 😄
ellisonbg commentedon Sep 6, 2015
I also think the notebook backend should always use a widget.
fariza commentedon Sep 22, 2015
@blink1073 did you see structure of
ToolManagerand the interaction withTools(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.
blink1073 commentedon Sep 22, 2015
I was only planning to attack the "which websocket" and "which div" part of the equation, at least to start.
OceanWolf commentedon Sep 22, 2015
Not sure if that will overlap, I haven't seen much of the code of
NbAggyet, onlyWebAggwhich 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 easyTkAggbefore resumingWebAggand fix upNbAgg.