Widgets

[jasongrout]

• Checking the recent ipywidgets changes with the current hack in the notebook to make sure the framework still works well
• Make an easy way to transform from backbone views to phosphor views that are displayed. Perhaps at the WidgetManager displaying logic level.
  • Minimally wrap widgets
  • Get it working in the new notebook
• Clean up each view, removing jquery and bootstrap dependencies
  • Rewrite tab widget with phosphor tabs
  • accordion widget
  • test controller view
  • all other cleanups

Widget output system

• JASON email the list for comments on changing how widgets are displayed
• JASON Fix widget python code to use ipython display system instead of comm messages
  • adding a widget renderer to the transformime code to be able to display widgets in the output area of a cell. This would take the widget data {'application/jupyter-widget': 'model-id-of-widget'}.
• Output area widget
  • ping Jon
  • Python side: capture output messages with a context manager and store them instead in the widget state
  • javascript side: give the appropriate transformime instance to the output widget view so that it can render the outputs
• Creating an output display class that takes in the widget mimetype and displays the correct model in the appropriate place in the output area.

ow1 = OutputWidget()

display(ow1) # send display_data message

with ow1.capture(): # or with ow1:
   plot(x,y)
with ow2.capture()
   plot(x2,y2)

ow1.clear_output()

x = IntSlider()
display(x)
display(plot(data, data*x.value))
def x_change(name, value):
    clear_output()
    plot(data, data*x.value)
x.on_trait_change(x_change)

[jasongrout]

CCing @jdfreder, @SylvainCorlay @sccolbert @dwillmer @blink1073 @afshin

[blink1073]

Ref: jupyter/jupyter-js-plugins#89, which demonstrated a functioning slider using jupyter-js-widgets@0.0.14.

[jasongrout]

@jdfreder, @SylvainCorlay - is that a current enough version of jupyter-js-widgets to build on? Or are there unreleased changes that we should test? Sylvain was mentioning that maybe we should bump the jupyter-js-widgets version to have the latest...

[jasongrout]

Sylvain pointed out that ipywidgets needs an update to deal with the most recent jupyter-js-services: jupyter-widgets/ipywidgets#381

[jasongrout]

Actually, that issue may not impact us, because we handle hooking the widget manager up to comm targets ourselves.

[jdfreder]

That may actually be closed by jupyter-widgets/ipywidgets#382 . I pinged the author

[parente]

/cc @lbustelo @jhpedemonte

[ellisonbg]

please cc @fperez and myself on this stuff...

[ellisonbg]

Also, I am concerned about "getting the notebook working in JupyterLab" becoming a much larger "completely redesign the notebook" that delays JupyterLab too much. I would prefer to first get the same (features, design, UX, etc) notebook (but refactored code) working in JupyterLab so users have full feature parity and then begin to evolve it in subsequent major releases.

[jasongrout]

Please keep in mind that these changes for widgets are to "refactor" the widget code to finally complete the separation we couldn't quite do because of hardcoded hacks in the current notebook. It also makes it work with the design we're doing here a lot better.

I also am trying to be conservative about the changes in this initial release. I think finally being able to clean out the widget code out of the main notebook is a good thing and will make things easier and better in the short and long run.

[jdfreder]

I think this work will also improve the lives of other people using widgets outside of the context of the notebook already, like our friends at IBM.

[jasongrout]

I just realized a big problem with having a global renderer for display_data messages that is supposed to render notebook-specific widgets - of course the global renderer does not have access to notebook-specific state, so you can't just say "render widget model id blah" and have it know what to do, because all it gets is the message and nothing else.

Some workarounds:

1. put all widget state in the display_data message, a la react. Then the widget renderer doesn't ever need notebook state to render a widget. Widget state is automatically stored in the notebook format.
2. We could have a notebook extension service. A plugin can register a callback with the notebook extension service. When a new notebook is created, the callback is called with extension points for the specific notebook (e.g., functions to register comm targets, notebook-specific mime renderers, etc.). The callback returns a disposable object. When the notebook is destroyed, it disposes the object.

CC @jdfreder, @blink1073

[parente]

@jasongrout By "global renderer" and "notebook-specific widgets", do you mean that there is one display_data function in the app container that handles rendering for multiple notebook document views? I ask because I'm curious what problem you hit that we haven't yet hit in the dashboard_server where we have one display_data function ...