Jupyter Blog - widgets

ipydatagrid is now part of Project Jupyter

2024-08-22T15:01:00+00:00

Today, we are proud to announce that the ipydatagrid open source project has been incorporated into Project Jupyter as part of the Jupyter Widgets subproject.

What is ipydatagrid?

ipydatagrid is a fast data grid widget for Jupyter Notebooks and JupyterLab. Since its inception in 2019, it has been developed as an open source project in Bloomberg’s GitHub organization.

It offers a high-performance fully-featured DataGrid interface, fully integrated with ipywidgets. Built upon the Lumino datagrid, which also powers the JupyterLab CSV viewer, ipydatagrid provides users with a robust and versatile tool for data visualization and manipulation.

Key Features

Users can customize the way data is represented in their grid using a variety of renderers.

ipydatagrid includes a sophisticated selection model with two-way data binding.

It enables conditional formatting powered by Vega Expressions.

The transfer to Project Jupyter

We would like to extend our gratitude to the developers and contributors who have significantly improved the ipydatagrid project over the years: Itay Dafna, Martin Renou, Mehmet Bektas, Kaia Young, Bernát Gábor, Vasilis Themelis, Supriya K., Greg Mooney, Ian Thomas, Olly Hensby, and John Gunstone. Special thanks to Chris Colbert, the creator of the Lumino Datagrid, which forms the foundation of ipydatagrid’s front-end.

Bloomberg’s contribution to Project Jupyter

The transfer of ipydatagrid to Project Jupyter is just one of many contributions that Bloomberg has made to Project Jupyter. As a long-standing sponsor, Bloomberg has been instrumental in the development and success of Jupyter. Home to core maintainers and a major funder of JupyterLab since its inception, Bloomberg has also sponsored all editions of JupyterCon. The sustained support by Bloomberg has been crucial to Jupyter’s growth and impact.

We are excited about the future of ipydatagrid within Project Jupyter, and look forward to continued innovation and collaboration within the broader community.

— on behalf of the Jupyter Widgets Council, Sylvain Corlay

Make your Pandas or Polars DataFrames Interactive with ITables 2.0

2024-03-19T18:39:00+00:00

ITables, or Interactive Tables, is a MIT-licensed Python package that renders Python DataFrames using the DataTables JavaScript library. ITables 2.0, that I have just released, adds support for the DataTables Extensions. In this post we review the functionalities brought by this release.

How to use ITables, and what you get

ITables can be installed using either pip or conda:

pip install itables

conda install itables

ITables is essentially a Python wrapper for DataTables. We have managed to keep its dependencies to a minimum: ITables only requires IPython, pandas and numpy, which you must already have if you use Pandas in Jupyter (add polars and pyarrow if you wish to use ITables with Polars DataFrames).

To use ITables in your notebook, run this code snippet:

from itables import init_notebook_mode

init_notebook_mode(all_interactive=True)

After that, every Pandas or Polars DataFrame will be displayed using the DataTables library. With DataTables, you get an easier and more complete access to your data. You can expand the table, explore the various pages, sort the data or even search through it, without having to go back to the Python prompt.

A Pandas DataFrame rendered with ITables

To render only specific tables as interactive DataTables, or pass arguments to the DataTable constructor, you can use the show function:

from itables import show

A brief history of ITables

I started the ITables project back in 2019. The full changelog is available here, but let me highlight a few important milestones:

v1.0 (June 2022): Offline mode
v1.2 (Aug 2022): In addition to Jupyter Lab, Notebook, Book, HTML export, VS Code, PyCharm, Google Colab, RISE presentations, Voilà applications, ITables works in Shiny applications
v1.3.5 (Nov 2022): Large tables are fast too
v1.5 (March 2023): Polars DataFrames are supported
v1.6 (Sep 2023): Pandas Style objects can be displayed with ITables
v1.7 (Feb 2024): ITables works with Quarto
v2.0 (March 2024): ITables support the DataTables Extensions!

It took me much research (and two years I am afraid) to reach v2 and the DataTables Extensions. But we’re finally there! Let’s review what these extensions mean to your data workflow.

My favorite DataTables Extensions

Download your data!

If you think of a Jupyter Notebook, it might sound strange that we are considering downloading the table data, since we have it already in the Python session. Actually, ITables does not stop at the Notebook. The interactive DataTables continue to be interactive even if you export the notebook to an HTML document with e.g. Jupyter nbconvert (jupyter nbconvert --to html). The are also interactive in a RISE or Quarto presentation. ITables also works in Jupyter Book (which we use for the ITables documentation), and in interactive applications build with e.g. Voilà or Shiny.

Hopefully it’s clearer now why we might want to make the data downloadable! And the good news is that, with the Buttons extension of DataTables, is it as easy as:

show(df, buttons=["copyHtml5", "csvHtml5", "excelHtml5"])

The Copy/CSV/Excel buttons

Cascade search

The SearchPanes extension lets you proceed to a quick and visual search through the columns that have repeated values:

The SearchPanes extension

Search builder

I find the SearchBuilder extension very useful. Also, I love the option to set a pre-defined search and display only the part of the dataset we want to focus on.

The SearchBuilder extension

Downsampling

Last but not least, I need to tell you about ITables’ down-sampling mechanism. By default, only a subset of the table with an estimated size of not more than 64kB (and not more than 200 columns) is displayed. You can change this with e.g.

import itables.options as opt

opt.maxBytes = 131072
opt.maxColumns = 0

You can tell whether your table was down-sampled by looking at the table summary at the bottom right of your table.

Please keep the following in mind: when down-sampling occurs, only a fraction of the data is passed on to DataTables, and hence the search or data export functions will only have access to that partial dataset.

Down-sampling is what makes ITables fast. Think twice before setting opt.maxBytes to a large number or to 0, as this might well freeze your notebook. Displaying a 1G DataFrame will make your notebook at least as big (probably bigger as the data is exported to JSON), and it’s not clear that your browser will support this.

Acknowledgments

ITables would not exist without the beautiful DataTables JavaScript library. The DataTables library (MIT license) is authored and maintained by Allan Jardine. DataTables has a great documentation, many examples, and also a useful forum. Allan also provided precious advice on how to bundle the extensions with ITables.

The point in using DataTables in the context of data exploration and analysis had been demonstrated prior to ITables by the DT package for R.

Last but not least, ITables owes a lot to my brother François Wouts. François patiently helped me find a way to provide DataTables and its extensions that would be compatible with all the editors and rendering contexts that we want to support in ITables.

anywidget: Jupyter Widgets Made Easy

2023-07-11T23:09:00+00:00

anywidget is a Python library that makes it simple and enjoyable to create custom Jupyter Widgets that run in classic Jupyter notebooks, JupyterLite, JupyterLab, Google Colab, VS Code, and more. It focuses on:

Prototyping*: Create custom widgets right within your notebook.*
Portability*: Share widgets as Python scripts or pip-installable packages.*
Productivity: Enjoy a modern front-end developer experience that supports real-time updates and removes manual project setup and other boilerplate.

anywidget enables real-time widget development entirely from within JupyterLab

Skip ahead to see an example.

Why making widgets is hard

Jupyter Widgets enrich notebooks with interactive JavaScript-based views and controls for Python objects in the Jupyter kernel. They enable a wide range of users, from students to professionals, to tailor their programming environment with custom or ready-made tools to interact with their programs and explore data. Consider a machine learning researcher adjusting model parameters with a slider or a computational biologist navigating a genome browser programmatically.

Jupyter Widgets link JavaScript-based views and controls with objects in the Jupyter kernel

A useful feature of widgets is that they may be packaged and distributed as pip-installable modules, offering reusable components to address both general and specialized needs. For example, the ipywidgets project provides basic elements like form controls and layout containers, while numerous community projects offer custom widgets for domain-specific tasks (e.g., bqplot, ipyvolume, ipyleaflet).

Comparing two massive genomic contract matrices within Jupyter using a custom widget from higlass-python

However, the growing number of Jupyter environments supporting .ipynb files complicates custom widget creation and sharing:

Developers must individually adapt front-end code to meet subtle, often undocumented, requirements of each notebook platform.
Basic prototyping involves setting up a local Python package and manually installing extensions.
Proper widget distribution requires deep understanding of both Python and JavaScript packaging.

I’ve expanded on these challenges previously, but to put it simply: traditional widget development has a steep learning curve and maintenance is both error-prone and tedious.

anywidget introduces a fresh approach for creating and sharing custom widgets. It lets you avoid traditional development complexities, simplifying the process and making it easier than ever to start building widgets.

Development without anywidget

anywidget is not a new framework, but rather a compatibility layer around traditional Jupyter Widgets. It utilizes the standard module system now found in web browsers to let widget developers write front-end code that executes universally. Think of anywidget as an adapter that runs your widget’s JavaScript across various notebook environments.

Development with anywidget

With anywidget, a custom widget consists of two components: a Python class and an ECMAScript module (ESM) — or web-standard JavaScript. You just write ESM and anywidget handles the platform-specifics quirks.

It takes less than 20 lines of code to recreate a simple “Hello World” widget.

import anywidget
import traitlets

class ExampleWidget(anywidget.AnyWidget):
    _esm = """
    export function render({ model, el }) {
        el.classList.add("custom-widget");
        function valueChanged() {
            el.textContent = model.get("value");
        }
        valueChanged();
        model.on("change:value", valueChanged);
    }
    """
    _css = """
    .custom-widget {
        background-color: lightseagreen;
        padding: 0px 2px;
    }
    """
    value = traitlets.Unicode("Hello World").tag(sync=True)

ExampleWidget()

You can copy and paste this code directly into Jupyter notebooks, JupyterLite, JupyterLab, Google Colab, or VS Code and it just works.

No installation, build configuration, or bundlers.

By comparison, creating an identical ExampleWidget the traditional way involves forking a Python repo template (including ~50 files), building JavaScript source code with Node.js and webpack, and manually installing the local extensions in classic notebooks or JupyterLab (not compatible with Google Colab or VS Code).

A realistic example

This tutorial demonstrates using anywidget to address a long-standing issue in the Altair: retrieving data from a brush selection back into Python. You can either follow along here or execute the notebook yourself in Colab.

We’ll begin with an interactive scatterplot example from the Altair docs:

import altair as alt
from vega_datasets import data

source = data.cars()
brush = alt.selection_interval()

points = alt.Chart(source).mark_point().encode(
    x="Horsepower",
    y="Miles_per_Gallon",
    color=alt.condition(brush, "Origin", alt.value("lightgray"))
).add_params(
    brush
)

bars = alt.Chart(source).mark_bar().encode(
    y="Origin",
    color="Origin",
    x="count(Origin)"
).transform_filter(
    brush
)

points & bars

Notice how the brush selection on the scatter plot filters the data in the linked bar chart. Neat, but unfortunately we are unable inspect the selected points because the selection is processed in JavaScript, and Altair lacks a mechanism to communicate back to Python.

Sounds like a job for a widget!

Behind the scenes, Altair produces JSON that follows the Vega-Lite visualization grammar. With anywidget, we can create a custom widget to render this validated JSON independently and additionally relay the JavaScript-based selections back to Python.

import anywidget
import traitlets

class ChartWidget(anywidget.AnyWidget):
    _esm = """
    import embed from "https://cdn.jsdelivr.net/npm/vega-embed@6/+esm";
    
    export async function render({ model, el }) {
        let spec = JSON.parse(model.get("spec"));
        let api = await embed(el, spec);
        api.view.addSignalListener(spec.params[0].name, (_, update) => {
            console.log(update);
            model.set("selection", update);
            model.save_changes();
        });
    }
    """
    spec = traitlets.Unicode().tag(sync=True)
    selection = traitlets.Dict().tag(sync=True)

What’s happening here? Our custom ChartWidget is defined by subclassing anywidget.AnyWidget:

_esm (line 6) defines the ECMAScript module for the widget. It imports necessary rendering dependencies (vega-embed) and exports render: a function to displays the Vega-Lite chart and (importantly) links the JavaScript-based selection to Python.
spec and selection (lines 19–20) define stateful properties via traitlets that are accessible by both client JavaScript and Python. These represent the Vega-Lite JSON specification and the JavaScript-based brush selection.

Now our ESM takes care of rendering instead of Altair.

chart_widget = ChartWidget(spec=(points & bars).to_json())

# Prints updates log console (JupyterLab: View > Show Log Console)
chart_widget.observe(lambda selection: print(selection.new), names=["selection"])

chart_widget

The original cross-filtering behavior stays the same, but now we have access to the JavaScript selection in Python via chart_widget.selection. The Python callback (line 4) prints the synchronized selection in the JupyterLab log console any time it changes.

Finally, we can present this data more effectively using a second widget that displays our selection as pd.DataFrame.

import ipywidgets

output = ipywidgets.Output()

@output.capture(clear_output=True)
def on_change(change):
    df = source
    selection = change.new
    for field, (lower, upper) in selection.items():
        df = df[(df[field] > lower) & (df[field] < upper)]
    display(df)

chart_widget.observe(on_change, names=["selection"])
ipywidgets.VBox([chart_widget, output])

The on_change callback (line 6) is invoked whenever the chart_widget.selection changes (line 13). It filters the original data based on the selection bounds and displays the given subset as a table within output.

With just a few lines of code, we enhanced Altair with new functionality using anywidget.

The ChartWidget can be shared in its current state. However, if we add more features, we could transition the JavaScript code from inline strings to separate files, gradually evolving the widget into a fully-fledged Python package. This incremental development is a feature of anywidget, allowing prototypes to grow into robust tools over time.

Modern web development meets Jupyter

anywidget further embraces modern JavaScript to reduce friction and make developing widgets more accessible and fun.

Because anywidget takes care of all the necessary plumbing, you no longer need to setup up a local Python package or manually install extensions to start building. Instead, you can prototype and share widget ideas directly from notebooks — just like regular Python scripts.

Since v0.2, anywidget allows you to use a file path to define your widget’s front-end code (i.e., the _esm and _css attributes). During development, anywidget will monitor for changes and immediately refresh the UI without requiring a full page reload or resetting widget model state.

import anywidget
import traitlets

class ExampleWidget(anywidget.AnyWidget):
    _esm = "index.js"
    _css = "styles.css"
    value = traitlets.Unicode("Hello World").tag(sync=True)

This feature has been popularized by modern web frameworks, but anywidget introduces it for the first time to Jupyter. See this real-time development workflow it in action or try it out yourself!

Real-time widget development entirely from within JupyterLab

Try it out!

anywidget is available on GitHub and PyPI and may be installed via pip:

pip install "anywidget[dev]"

I hope using anywidget is simple and enjoyable. I have found it valuable in my work as a biomedical visualization researcher, and it’s been exciting to see the positive reception from the wider Jupyter community.

Since its release a few months ago, anywidget already been adopted by several notable projects:

Mosaic: an extensible framework for linking interactive views to databases for scalable data processing.
jupyter-scatter: interactive 2D scatter plots that scale to millions of points and support view linking.
Mapwidget: interactive 2D/3D maps using popular JavaScript libraries with bidirectional communication, such as Cesium, Mapbox, MapLibre, Leaflet, and OpenLayers
pyobsplot: a Python interface for Observable Plot that supports Pandas and Polars dataframes.
ipyreact: a Python library for authoring Jupyter Widgets with React components.

… demonstrating its current viability as an alternative to traditional widget development. I am committed to maintaining the simplicity that defines anywidget while exploring ideas to further modernize widgets like:

A simple decorator-based API
Using builtin dataclasses or libraries like Pydantic or msgspec to define widget models and serialization logic
Handling TypeScript and JSX for front-end code

If you’re curious about custom widgets or facing difficulties in widget development, please give anywidget a try and share your experience. Happy coding!

GitHub - anywidget: custom jupyter widgets made easy

I’d like to extend my gratitude to the numerous contributors to our documentation and specifically Talley Lambert for his work towards modernizing widgets from a Python perspective. He’s played a key role in developing our experimental API, which allows more flexible communication between JavaScript and Python without requiring ipywidgets.

Jupyter Community Workshop: The Future of Jupyter Widgets

2022-09-20T17:02:00+00:00

After a long break from in-person events, we are excited to announce an in-person Jupyter Community Workshop!

Jupyter Community Workshops is a series of community-organized events to tackle challenging development and design projects, growing the community of contributors, and strengthening collaborations.

ipywidgets 8.0 was released earlier this year, and we are now looking at the future of Jupyter Widgets with versions 9 and beyond of ipywidgets. Some topics we are looking to discuss (non-exhaustive list) include the embedding of widgets in iframes, the next iteration of the Jupyter comm protocol, visual and styling improvements, and the embedding of Jupyter Widgets in contexts outside of Jupyter Notebook/Lab.

The workshop dates are 18th-21st of October. It will take place in the Bloomberg EMEA headquarters in London. Travel funding assistance is available for attendees from academia and those from groups which are not well-represented within the Jupyter and wider tech community!

Registration and all other details can be found in the link below: Jupyter Community Workshop: The Future of Jupyter Widgets (bloomberg.com)

We are really excited for this community workshop and hope you will join us!

We are grateful to Bloomberg for hosting this event. We are also grateful to the sponsors of the Jupyter Community Workshop series, Bloomberg and Amazon AWS.

Jupyter Games

2021-12-14T19:38:00+00:00

Motivation

Making their own tiny video games can be a great way for kids to learn programming in a playful matter. While Jupyter is widely used as a scientific and educational tool, Jupyter is seldom used as a platform for game development. In this blog post, we show how Jupyter can be used to develop tiny games based on Box2D. While Jupyter is language agnostic and kernels exist for many programming languages, we will focus on the Python programming language in this blog post.

Mini-Games

When talking about video-games one might think of games such as:

Games as the ones above are usually developed with an engine like:

Not only do these games require complex engines to be developed, but also a whole team developing them and a lot of time and money.
Obviously, these are not the kind of games we can and want to develop in Jupyter. We want tiny games (~ 1000 lines of code) which can be implemented by kids in a matter of a few hours rather than many days, i.e. games like Pong, Pinball, and AngryBirds. In fact, we will focus on a certain class of games: 2D physics-based games, since these can be implemented very easily with the use of a 2D physics simulation engine like Box2D or Chipmunk2D.

Box2D

Box2D is a 2D rigid body simulation library for games. Box2D is best explained by the demo below.

A demo of Box2D compiled to JavaScript with Emscripten. Try it out (only HTTP, no HTTPS 😢 )

Box2D makes it very easy to implement physics-based games like Angry Birds or World of Goo.

Box2D Debug Draw

DebugDraw

Box2D has an abstract class DebugDraw with a handful of methods to draw simple primitives. The API is given by the following:

Box2D DebugDraw API

The ipycanvas based Box2D debug draw in action

Implementing this abstract class allows you to draw the physics for your UI back-end. Box2D is shipped with a glfw based DebugDraw implementation. For Python one can implement a pygame or kivy based DebugDraw implementation. For a finished product, one wants to replace the debug-draw-based renderings with custom shiny rendering routines. But using only debug-draw-based renderings is more than enough to quickly test game ideas and play around with Box2D.

LiquidFun

LiquidFun is a 2D rigid-body and fluid simulation library for games written in C++ based upon Box2D. LiquidFun is best explained by the demo below:

A demo of LiquidFun compiled to JavaScript with Emscripten which runs in the browser. Try it out!

More than just Games

Even though Box2D is advertised as a 2D physics engine for games, Box2D can also be used for educational purposes:
The YouTube channel iforce2d has done some impressive things with Box2D like a Box2D-based combustion engine and a wind tunnel.

Box2D based combustion engine by the youtuber iforce2d

Box2D based wind tunnel by the youtuber iforce2d

Box2D Python

Box2D has bindings for many languages and can be compiled to Wasm. Several Box2D demos exist:

http://www.iforce2d.net/embox2d/testbed.html (only HTTP, no HTTPS 😢 )
https://birchlabs.co.uk/liquidfun-wasm/
https://google.github.io/liquidfun/

We are particularly interested in using Box2D / LiquidFun from Python.
Here we have the following possibilities:

pybox2d

With pybox2d, Box2D has matured and robust Python bindings with extensive documentation. Unfortunately, pybox2d has a few shortcomings:

It only works with an old version of Box2D.
There is no support for LiquidFun.
pybox2d is mostly unmaintained.
The Python bindings are generated with SIWG (not really a shortcoming, but I personally strongly prefer pybind11).

pyb2d

A disclaimer first, I am the author of the pyb2d Box2D Python bindings. The motivation for creating pyb2d was having Box2D / LiquidFun bindings created with pybind11. While pyb2d works with the brand-new 2.4.1 release of Box2D, has support for LiquidFun and pybind11 has been used for generating the Python bindings, there are also some downsides:

pyb2d has fewer examples compared to pybox2d
pyb2d is not as mature and robust as pybox2d
pyb2d is not yet as well documented as pybox2d

A particularly useful feature of pyb2d is its BatchDebugDraw implementation: While we could implement the above mentioned debug draw API directly in Python, this would have a few drawbacks:

There is a certain overhead when calling C++ from Python and vice versa. When our game contains a lot of shapes, for instance circles, we would have to call drawCircle very often and have a lot of calls from C++ to Python and vice versa.
Some back-ends provide batch-drawing capabilities such that we can draw multiple primitives at once. For instance, drawing 100 circles at different locations with a single function call where the function arguments are NumPy nd-arrays with the centers/radii of the circles. Using such a batch API can lead to tremendous speedups.

The python batch debug draw API of pyb2d

To address these issues pyb2d provides a BatchDebugDraw implementation where we first collect all the individual calls like drawCircle, drawSegment, drawPolygon etc. We store the arguments of these calls in NumPy arrays. After collecting all the shapes we call the Python API with functions like draw_circles, draw_segments, draw_polygons, etc. where all the shapes are passed to Python in a single function call. On the Python side, one can pass these batched draw instructions to a batch-drawing API of the UI backed. (Spoiler: We will use the batch drawing API of ipycanvas for the Jupyter pyb2d integration.)

Jupyter Box2D Integration: Requirements

To have a platform to develop tiny games from within Jupyter we need at least the following:

A Canvas: We need a surface/canvas on which we can draw the content of the games.
Input Devices: Games would be boring without any user input. We need access to input devices like the mouse, the keyboard or even game-pads.

Ipycanvas, Ipywidgets, Ipyevents

Jupyter has a huge ecosystem of extensions. For the Jupyter Box2D integration, we just need to pick the appropriate Jupyter extensions: Ipycanvas gives us access to the HTML Canvas from within Python kernels in Jupyter. This serves as the drawable surface for our games. Ipywidets and Ipyevents give us access to input devices like game-pads, the keyboard, and the mouse.

Ipycanvas

Ipycanvas is a lightweight library developed by Martin Renou exposing the browser’s Canvas API to Jupyter. It allows drawing simple primitives directly from Python like text, lines, polygons, arcs, images, etc. With a few tricks, ipycanvas is fast enough to draw smooth animations. This even works when the server and the client are not on the same machines (when we run ipycanvas on MyBinder for example).

Conways game of life in ipycanvas, try it out!

An Ipycanvas-based DebugDraw:

The first step of integrating pyb2d in Jupyter notebooks is implementing an ipycanvas based DebugDraw. We recently released a new version of ipycanvas which provides an extended batch API to draw things very fast. We utilize this batch API when implementing the above mention batch-debug-draw API.

Handling events in Jupyter:

We can use Ipyevents for the event handling in Jupyter. Obviously, we want to handle the events while our game is running. To achieve this within a Jupyter-notebook we need to run our game-loop in a dedicated thread and listen for events in the main thread.

Adding Buttons:

We want to have a few buttons to start, pause and reset the Box2D based games. We can add these with ipywidgets.

Putting it all together

With all the above we can put together a pyb2d based Python Box2D integration in Jupyter. As a proof of concept we implemented a few mini-games:

Billiard:

A very simple billiard game. Try it on binder!

Angry Shapes:

An Angry Birds-like game implemented with pyb2d. Try it on binder!

World of Goo homage:

A World of Goo homage implemented with pyb2d. Try it on binder!

Rocket:

Fly a rocket controlled with the keyboard, but avoid the black hole! Try it on binder!

Compatibility

All the pyb2d examples shown above can also be run in a pygame window or a kivy window since pyb2d also provides back-ends for these. But even when one prefers to experiment with pygame, the Jupyter back-end can still be interesting since one can put the testbed-examples on MyBinder and have them accessible in a convenient fashion.

Caveats

The Jupyter integration of pyb2d gives usable frame rates, even when run through MyBinder. But nevertheless, a pygame based back-end usually leads to a better frame rate and smoother gameplay.

Outlook / Sneak preview

We currently work on:

Adding more examples and better documentation to pyb2d.
Improve the performance of the Jupyter integration.
Add pyb2d to JupyterLite.
Implement remote multiplayer-based gaming via the collaborative mode of JupyterLab.

Sneak-preview: Via the collaborative mode of JupyterLab we can connect to the notebook from two machines and play billiard against each other.

Acknowledgments

I would like to thank Martin Renou for his help with ipycanvas.

About the author

Thorsten Beier is a Scientific Software Engineer at QuantStack. Before joining QuantStack, he graduated in computer science at the University of Heidelberg and worked at the EMBL. As an open-source developer, Thorsten worked on a variety of projects, from nifty and vigra in C++ to inferno, kipoi, and ilastik in Python.

Build a Jupyter Widget with React and TypeScript

2021-07-30T19:02:00+00:00

Photo by Adi Goldstein on Unsplash

When using a Jupyter Notebook to work on data science projects, I’ve found small user interface abstractions to be very useful. Scrubbing a slider or uploading a file can be more intuitive than editing a script and running it manually. This is especially true when a notebook is shared with others, since most people already have a basic knowledge about user interface elements.

Jupyter Widgets are fantastic tools for simplifying Jupyter Notebook workflows with custom user interfaces. While widgets are versatile and composable, sometimes the default implementations provided by Jupyter don’t have the exact functionality we are looking for. Luckily, we are able to create Custom Widgets to suit our needs using web technologies. To get an idea of how Custom Widgets work, we are going to build a sleek color picker for JupyterLab using React.

Setup

Before we can start coding, there is some basic boilerplate to download. Start by installing cookiecutter.

pip install cookiecutter

Then download the React widget boilerplate code.

cookiecutter https://github.com/Waidhoferj/jupyter-widget-react-cookiecutter.git

The cookiecutter template will guide us through some setup questions. The author_name, author_email, and github_project_name fields are the most important. We can leave the others blank or go with the default values.

Next, create a development environment using Anaconda:

conda create -n jupyter-react-widget -c conda-forge nodejs yarn python jupyterlab

conda activate jupyter-react-widget

Every package we install for this project will now be contained in a neat bundle.

Inside the project directory created by cookiecutter, run the following script to install the dependencies that we’ll use to build the widget. Then connect our widget environment to JupyterLab:

pip install -e ".[test, examples]"

jupyter labextension develop --overwrite .

yarn run build

Thats it for the setup! Let’s see what the default widget can do.

To test out the widget, run jlpm watch in the project directory and open up JupyterLab with jupyter lab in another terminal window. In JuypterLab, open the notebook file located at /examples/introduction.ipynb. Run all of the notebook cells to examine the state of the widget. In its current form, the widget displays a greeting alongside an input text field. Typing into the input field will update the target of the greeting. The value of the text box is automatically synced with w.value, allowing us to access the input’s contents as a Python string. With the default setup working, we can start designing our own custom widget.

Building a Color Picker

Let’s take a look at the architecture of a Custom Widget. The Jupyter Widget system allows developers to send data between Python and TypeScript using a Model-View-Controller Architecture. The Python Widget Model represents the state of the widget. The TypeScript Controller edits and responds to changes in the Python model based on user input. These updates are rendered in the notebook using React.

Data is passed from the Python model to the TypeScript controller to the React view and back

We can start building our color picker in example.py by adding a color property to the model.

class ExampleWidget(DOMWidget):
    ...
    # Your widget state goes here. Make sure to update the corresponding
    # JavaScript widget state (defaultModelProperties) in widget.ts
    value = Unicode('Jupyter').tag(sync=True)
    color = Unicode('Jupyter').tag(sync=True)

The color property is set equal to the Unicode traitlet, which represents a string of characters. The .tag(sync=True) method syncs the value of the color property with the TypeScript widget state.

In widget.ts, we define the corresponding TypeScript representation of color in the defaultModelProperties object. This object mirrors the structure of the Python model, allowing us to access the model state in our frontend code.

const defaultModelProperties = {
  value: 'Hello World',
  color: '',
};

Add color to the default model properties object

Now that we have defined our model, the rest of the work can be done in React. If you’d like to flex your web development skills and design a custom color picker, go for it! Alternatively, we can get a great plug-and-play interface by installing react-colorful:

jlpm add react-colorful

Create a ColorPicker.tsx file in the src folder. We can build out the component in a few lines of code:

import React from 'react';
import { HexColorPicker } from 'react-colorful';
import { useModelState } from './hooks/widget-model';

export default function ColorPicker() {
  const [color, setColor] = useModelState('color');

  return <HexColorPicker color={color} onChange={setColor} />;
}

The ColorPicker React component

Let’s walk through what’s happening here. At the top of the file, we import React, the react-colorful component, and a hook called useModelState. The useModelState hook operates like the useState hook but instead of accepting a default value as a parameter, it takes the name of a property from our Python model. The hook will automatically update the React view when the referenced property updates in Python. Also, the React widget can directly update the Python model with the setColor function. By passing color and setColor to the HexColorPicker, the Python widget model will reflect the chosen color whenever the user makes a selection in the interface.

To display the color picker in our notebook, add the component to ReactWidget.tsx, which is the top level React file in the widget system. Import the ColorPicker component at the top of the file and make it the return value of ReactWidget. We can delete all of the boilerplate within the ReactWidget component in the process. Additionally, delete the useModelState import at the top of the file, since it is no longer needed.

import ColorPicker from './ColorPicker';
...
function ReactWidget(props: WidgetProps) {
  return <ColorPicker />;
}

Add ColorPicker to ReactWidget

To test this out, restart the python kernel in JupyterLab and refresh the browser window. We will now see a color picker where the input field used to be. Pick a color and print out w.color to get the hex code in Python. Congrats! You now know how to create Jupyter Widgets using React!

The principles that we covered here can be applied to create more complex applications. To add additional properties, define them in both example.py and widget.ts, then interact with the data via the useModelState hook in a React component. Go build some amazing widgets!

Resources

A Curiously Recurring Widget Library

2021-01-27T14:22:00+00:00

Diving into the implementation of xwidgets

Interactive widgets allow Jupyter users to create user interfaces inline in their notebooks, and to turn them into standalone applications with tools such as Voilà.

Language backends for Jupyter interactive widgets exist in Python (with ipywidgets), and C++ (with xwidgets, and the xeus-cling C++ Jupyter kernel), reusing the same frontend implementation of the widgets in JavaScript.

Simple interactive widgets at play in JupyterLab with the xeus-cling C++ kernel

In this article, we dive into some of the C++ techniques used in the implementation of the xwidgets library, including

discussions on value semantics and RAII (Resource Acquisition Is Initialization),
an original application of CRTP (Curiously Recurring Template Pattern),
an original implementation of the observer pattern, xproperty,
a plea for allowing the overloading of the dot operator in C++, to enable better proxy types.

For readers interested in knowing more about interpreted C++, we recommend the following posts:

Interactive workflows for C++ with Jupyter (Jupyter blog), by Sylvain Corlay, Loic Gouarin, Johan Mabille, and Wolf Vollprecht.
- Interactive C++ for Data Science (LLVM blog), by Vassil Vassilev, David Lange, Simeon Ehrig, and Sylvain Corlay
- Interpreted C++ for GIS with Jupyter (Jupyter blog), by Martin Renou

Jupyter widgets are special objects that trigger the creation of a counterpart JavaScript model object in the Jupyter frontend upon creation. The state of the object in the backend is synchronized with the state of the JavaScript frontend object. Views of that widget model are instantiated upon display.

The MVC (Model View Controller) architecture of Jupyter widgets, and synchronization with the backend

This MVC (Model-View-Controller) architecture for Jupyter interactive widgets allowed us to reuse all of the frontend implementation, by simply providing an alternative backend in C++, implementing the same messaging protocol.

In order to tie the lifetime of the kernel and frontend objects, we decided to use the RAII (Resource Acquisition Is Initialization) pattern. RAII is a common programming idiom that consists of tying the lifetime of an object with the holding of a resource. Most typically, the resource is

acquired in the constructor of the object,
released in the destructor of the object.

The RAII pattern is not common in garbage-collected languages because unlike in C++, the time when objects are destroyed is not deterministic. The Python programming language mitigates that issue by introducing context managers, often used to e.g. open and close files.

A consequence of relying on object lifetime for resource management in C++ is to adopt the “value semantics” for widget instances, instead of “reference semantics” which is more typical for widget frameworks like Qt.

Note: value semantics vs reference semantics

If you are not familiar with the concepts of value and reference semantics in C++, I recommend reading the excellent FAQ of isocpp.org.

To summarize:

- with value semantics, objects hold actual values, and copying an object copies their attributes. With value semantics, one should provide implementations of copy, and move constructors*, as well as* copy and move assignment operators*. Besides, values should not have virtual methods.*

- with reference semantics*, objects are manipulated through references (or pointers) and never by value. Reference semantics is typically used for polymorphic programming with* virtual methods*. With reference semantics, it is recommended to delete copy and move constructors, as well as copy and move assignment operators to avoid accidental copies when passing objects to functions taking arguments by values, causing object slicing. (They can also be made private). Explicit cloning of a reference semantics object is generally allowed via a call to a* clone virtual method.

In a C++ codebase, the existence of public copy or move constructors alongside virtual methods in the same class is generally a sign of a bad design.

The use of value semantics for xwidgets provides clear lifetime management for associated resources. Careful use of the move semantics provides fine-grained control.

Illustration of the move semantics for xwidgets

Another advantage of using value semantics in xwidgets is that C++ beginners who are typical users of the Jupyter notebook (often used by instructors) can easily manipulate “widgets as values” without having to deal with manual memory allocation etc.

With value semantics, addressing the lifetime of objects becomes the responsibility of the framework author, in a carefull implementation of (copy and move) constructors, destructors, and (copy and move) assignment operators.

Static polymorphism and the CRTP pattern

While the use of value semantics provides fine-grained control over the lifetime of widgets, it prevents the use of virtual methods in their implementation. Code reuse is achieved with static polymorphism techniques and specifically the CRTP pattern.

The Curiously Recurring Template Pattern (CRTP) is the practice of making a class X derive from a class template instantiation using X itself as a template argument.

class X : public base<X>

CRTP is commonly used by matrix or tensor algebra libraries making use of expression templates (such as xtensor, eigen, or blitz) to prevent the overhead of virtual function dispatch for operations likely to be performed in a loop, such as element access.

Placing common code in a CRTP base allows code reuse without the overhead of virtual dispatch. However, the template base class is specialized for each final type increasing the resulting binary size. This can be mitigated by factoring as much of the code in a base class that would not be templated by the derived type.

CRTP in xwidgets — closing the recursion

In order to allow for code reuse without virtual inheritance, xwidgets’ class hierarchy is entirely based on CRTP. Our naming scheme is that CRTP bases, which should not be instantiated directly are prefixed with the letter x and final concrete widget types are not.

Upon construction of e.g. the button widget, constructors of base types are called in the order of inheritance, which is why we need to establish the connection with the frontend in the constructor of the most derived type, after all attributes have been initialized, and send a message to the frontend with all the values.

The pattern for creating the most derived type being always the same, we defined the xmaterialize template class closing the CRTP hierarchy with

using button = xmaterialize<xbutton>;

The xmaterialize template class is defined as final, to prevent further inheritance. The constructors and assignment operators forward to those of the CRTP bases and implement the RAII pattern.

template <template <class> class B, class... P>
class xmaterialize final : public B<xmaterialize<B, P...>>
{
public:

    using self_type = xmaterialize<B, P...>;
    using base_type = B<self_type>;

    template <class... A>
    xmaterialize(A&&...)
        : base_type(std::forward<A>(args)...)
    {
        this->open();      //  RAII: create the frontend model.
    }

    template <template <class> class B, class... P>
    inline xmaterialize<B, P...>::~xmaterialize()
    {
        if (!this->moved_from())
        {
            this->close();  // RAII: delete the frontend model.
        }
    }

...

};

The full implementation of xmaterialize (as of xwidgets 0.25) is available here. Beyond the logic described in this section, it also includes the handling of the move semantics and the method chaining API which is the subject of a later section.

Precompilation and binary size optimization

Even though xwidgets is fully based on template types, we decided to precompile all final widget types for faster interactive use with the xeus-cling kernel. This is achieved with

an extern declaration in the header (here in xbutton.hpp)

extern template class xmaterialize<xbutton>;

and in the source file (here in xbutton.cpp), an instruction for the precompilation

template class XWIDGETS_API xmaterialize<xbutton>;

Doing this for all widget types of the library initially resulted in a large compiled binary size. Using the button widget as an example, we see that base types are templated by the final type in the class hierarchy button -> xbutton<button> -> xwidgets<button> -> xobject<button>, and therefore, their binary representation is duplicated for each final type.

A strategy for reducing the binary size has been to factor out as much of the logic of xobject<D> in a non-template base xcommon improving compilation speed and preventing binary code duplication.

Xproperty: an implementation of the observer pattern

In order to update the frontend upon changes of widget properties, xwidgets relies on an implementation of the observer pattern called xproperty. xproperty is to xwidgets what traitlets are to ipywidgets.

In order to trigger observers and validators in the owner object upon assignment of new values, xproperty relies on the overload of the assignment operator =.

template <class T, class O>
template <class V>
inline auto xproperty<T, O>::operator=(V&& value) -> reference
{
    // Before assigning the new value, invoke validators
    // which may also mutate the value.
    m_value = owner()->template invoke_validators<T>(m_name, std::forward<V>(value));

    // Call class-level observer.
    owner()->notify(m_name, m_value);

    // Call registered observers for that attribute
    owner()->invoke_observers(m_name);

    // Return the new value 
    return m_value;
}

Jupyter interactive widgets have many attributes that may be specified at construction time.

In the Python implementation, this is handled with keyword arguments, but the C++ programming language does not support keyword arguments. There exist various approaches to enable this feature with advanced metaprogramming techniques. In the case of xwidgets, this need is limited to the initialization of xproperty attributes, which allowed us to adopt a more scoped approach: a method chaining API for property initialization:

auto slider = slider<double>::initialize()
  .min(-1.0)
  .max(1.0)
  .description("Another slider")
.finalize();

this was enabled by overriding the function call operator () on xproperties to pass an intial value (only when the said property is an rvalue). A static initialize method is used instead of the default constructor to prevent the initialization of the JavaScript counterpart while all attributes may not have been set yet. The frontend counterpart is only acquired with the finalize() call.

Building upon xwidgets

Jupyter interactive widgets are not limited to the controls available in the core package. In fact, there is a rich ecosystem of widget libraries built upon the core framework: ipyvolume (3-D plotting), ipyleaflet (maps visualization), bqplot (2-D plotting), ipygany (3-D mesh visualization), ipycanvas (generic drawing), ipywebrtc (streaming video and audio), and many many more.

For the C++ programming language, we have already provided:

xleaflet (the C++ equivalent to ipyleaflet, reusing the same frontend),
xwebrtc (the C++ equivalent to ipywebrtc, reusing the same frontend).

Screencast of xleaflet in JupyterLab, loading and visualizing a GeoJSON dataset in a C++ notebook.

Potentially, C++ backend to all Jupyter interactive widget packages could be provided, creating a huge opportunity for interactive data visualization in C++.

C++ should allow overloading the dot operator

xwidgets and xproperty makes heavy use of value semantics, and proxy objects.

At the moment, to access an attribute or method of a value held in an xproperty object, we must first call the function call operator () to access the undelying object first, which is cumbersome.
This is also an issue in other places in the xwidgets stack, when making use of e.g. reference proxies.

Being able to automatically map all methods of the underlying type to be accessible in the xproperty would be incredibly powerful, and remove the need for explicitly accessing the underlying.

Interestingly, the C++ standard does have the equivalent operator overload when it comes to pointer semantics, with the arrow operator ->. If overloading the dot operator . was allowed, this could enable this kind of usecase:

struct V
{
    void f();
};

struct X
{
    V& operator.() { return m_value; }
    V m_value;
};

in which case, X::f would call V::f .

Allowing the overloading of the dot operator . would also enable usecases such as smart references (similar to smart pointers, but with value semantics) and fully-fledged reference proxies (such as the return type of operator[] for std::vector<bool>).

Try it online!

Thanks to MyBinder, you can try xwidgets without the need of installing anything on your computer. Just follow this link:

About the author

Sylvain Corlay is the founder and CEO of QuantStack, an open-source software development studio comprising maintainers of key projects of the scientific computing ecosystem.

As an open-source developer, Sylvain is very active in the Jupyter project, contributing to the Xeus stack, Jupyter interactive widgets, Voilà dashboards. He is a member of the Jupyter steering committee and was the vice chair of JupyterCon 2020. Sylvain also contributes to the conda-forge project and he is the co-creator of the Xtensor C++ tensor algebra library.

Interactive Graph Visualization in Jupyter with ipycytoscape

2020-04-30T16:16:00+00:00

The Jupyter widgets ecosystem offers a broad variety of data visualization tools for exploratory analysis in the notebook. However, we lack a good story for exploratory graph visualization.

Cytoscape is an open-source software platform for visualizing complex networks and integrating these with any type of attribute data. While it comes from the computational biology community, cytoscape is fully-fledged general-purpose tool for graph visualization and analytics. It now includes a modern web front-end (Cytoscape.JS) which is a great candidate for integration with Project Jupyter. This is the raison d’être of ipycytoscape.

Gene visualization in ipycytoscape

The goal of ipycytoscape is to enable users of well-established libraries of the Python ecosystem like Pandas, NetworkX, and NumPy, to visualize their graph data in the Jupyter notebook, and enable them modify the visual outcome programmatically or graphically with a simple API and user interface.

Fortunately, Cytoscape offers a broad enough API that allows ipycytoscape to be a tool that can, in fact, be used to solve any type of problem modeled as a graph. Some examples consist in the development of new chemicals to analyze interactions between substances in the pharmaceutic industry, in security systems to create attack graphs that can be useful to show possible vulnerabilities in systems, modeling human behavior to understand people’s interaction with business or even to understand complex phenomena like the current crisis. Currently, there is an effort to make ipycytoscape an accessible tool for researchers that are trying to find ways to mitigate and understand it, there is more information about this initiative on the COVID OSS Help website and the discussion is happening in this repository if you’re interested in joining it.

Current state

IPycytoscape is part of the PLASMA project (aka in French, Plateforme d’eLearning pour l’Analyse de données Scientifiques MAssives). This project aims at creating an interactive tool to teach computational analysis of massive scientific data. Its first instance, PlasmaBio, is designed for the needs of teachers and students of the European Master of Genetics at Université de Paris. PlasmaBio provides an authentic experience of the actual genomic and bioinformatic analyses performed in research labs. For that purpose, a custom JupyterHub-based system to control many different Jupyter instances is being specially developed by Jeremy Tuloup at QuantStack.

In this first version of ipycytoscape, there are still some limitations to what you may be able to do, but there are also some extents from the Python world that will just work out of the box for you. ipycytoscape offers integration between Pandas DataFrames and NetworkX, meaning that you can have a graph visualization of the data you already have with minimal or none adjustments and just a few lines of code.

Usage with NetworkX and DataFrame

ipycytoscape supports all of the built-in CytoscapeJS layouts. This includes the cola, grid, breadthfirst, circular, concentric and Dagre layout as well as the random, null or preset options to build a graph visualization that fits better to your data .Additionally, ipycytoscape also supports the PopperJS and TippyJS extensions, that allows you to create customizable tips for your nodes and edges .

cola, concentric, dagre and grid layouts

You can also use a variety of labels for a quick visualization of your nodes’ and edges’ contents.

Labels on nodes

Like most Jupyter interactive widgets, ipycytoscape relies on the traitlets library to synchronize data between the back-end and the front-end model.

Unfortunately, traitlets have a limitation when it comes to container objects and other mutable structures, because synchronization is only triggered upon assignment of the container and not when modifying individual elements.

To work around this limitation, we make use of the excellent Spectate library by Ryan Morshead, which triggers observers upon individual element changes in containers.

Interaction between ipywidgets and ipycytoscape

Try it online!

You can try it without the need of installing anything on your computer just by clicking on the image below:

Installation

Note that you first need to have Jupyter installed on your computer. You can install ipycytoscape using pip:

pip install ipycytoscape

Or using conda:

conda install -c conda-forge ipycytoscape

If you use JupyterLab, you would need to install the JupyterLab extension for ipycanvas (this requires nodejs to be installed):

jupyter labextension install @jupyter-widgets/jupyterlab-manager jupyter-cytoscape

About the author

My name is Mariana Meireles and I’m a software developer working for QuantStack. I care deeply about the impacts that technology has in the world and try my best to be the change I want to see by contributing to open source projects that stand upon libre and diverse standards.

Prior to QuantStack I worked as a developer on the PySide team at the Qt Company and as a web performance developer at Mozilla.

Currently I’m working on expanding the Jupyter ecosystem with new libraries and functionalities, like an experimental SQLite kernel.

Acknowledgements

The development of ipycytoscape at QuantStack was funded as part of the PLASMA project, led by Claire Vandiedonck, Pierre Poulain, and Sandrine Caburet, associate professors at Université de Paris.

Sponsors to the PLASMA initiative include:

Région Île-de-France, via the “Trophées franciliens de l’innovation numérique dans le supérieur” (EdTech 2018) grant program,
Université de Paris, via the Initiative of Excellence (IdEx) Label and its “inovating teaching” grant program,
EUR G.E.N.E., the graduate school on Genetics and Epigenetics,
the university training “Création, analyse et valorisation de données biologiques omiques” (DU Omiques).

ipycanvas: A Python Canvas for Jupyter

2019-10-25T12:48:00+00:00

As you may already know, the Jupyter Notebook and JupyterLab are Browser-based applications. Browsers are incredibly powerful, they allow you to swap rich and interactive graphical interfaces containing buttons, sliders, maps, 2D and 3D plots and even video games in your webpages!

All this power is readily made available to the Python ecosystem by Jupyter interactive widgets libraries. Whether you want to create simple controls using ipywidgets, display interactive data on a 2D map with ipyleaflet, plot 2D data using bqplot or plot volumic data with ipyvolume, all of this is made possible thanks to the open-source community.

One powerful tool in the Browser is the HTML5 Canvas element, it allows you to draw 2D or 3D graphics on the webpage. There are two available APIs for the Canvas, the Canvas API which focuses on 2D graphics, and the WebGL API which uses hardware acceleration for 3D graphics.

After some discussions with my work colleague Wolf Vollprecht, we came to the conclusion that it would be a great idea to directly expose the Canvas API to IPython, without making any modification to it. And that’s how we came up with ipycanvas!

ipycanvas: Exposing the Canvas API to IPython

ipycanvas exposes the Canvas API to IPython, making it possible to draw anything you want on a Jupyter Notebook directly in Python! Anything is possible, you can draw custom heatmaps from NumPy arrays, you can implement your own 2D video-game, or you can create yet another IPython plotting library!

ipycanvas provides a low-level API that allows you to draw simple primitives like lines, polygons, arcs, text, images… Once you’re familiar with the API, you’re only limited by your own imagination!

Draw image from NumPy array (left), implementation of the Game Of Life (right)

Draw millions of particles (left), draw custom sprites (right)

Make your own plotting library for Jupyter fully in Python!

Using Matt Craig’s ipyevents library, you can add mouse and key events to the Canvas and react to user interactions.

If you have a GamePad around, you can also use the built-in Controller widget and make your own video-game in a Jupyter Notebook!

Documentation

Check-out the ipycanvas documentation for more information: ipycanvas.readthedocs.io

Github repository

Give it a star on Github if you like it! github.com/martinRenou/ipycanvas

Try it online!

You can try it without the need of installing anything on your computer just by clicking on the image below:

Installation

Note that you first need to have Jupyter installed on your computer. You can install ipycanvas using pip:

pip install ipycanvas

Or using conda:

conda install -c conda-forge ipycanvas

About the author

My name is Martin Renou, I am a Scientific Software Engineer at QuantStack. Before joining QuantStack, I studied at the aerospace engineering school SUPAERO in Toulouse, France. I also worked at Logilab in Paris and Enthought in Cambridge, UK. As an open-source developer at QuantStack, I worked on a variety of projects, from xtensor and xeus-python in C++ to ipyleaflet and ipywebrtc in Python and Javascript.

Introducing templates for Jupyter widgets layouts

2019-07-04T09:41:00+00:00

Notebooks come alive with Jupyter widgets, which allow users to produce interactive GUIs inline in the Jupyter notebook or JupyterLab.

You can either use them to add a few interactive controls and plots in notebooks or to create fully-fledged applications and interactive dashboards. Both can be built with components from the core built-in widgets such as buttons, sliders, and dropdowns, or with the rich ecosystem of custom widget libraries that built upon the Jupyter widgets framework, such as interactive maps with ipyleaflet or 2-D plots with bqplot. You can also combine several types of widgets together to create even richer applications.

Have you ever tried creating complex widget layouts with multiple widgets placed at specific locations? The preferred approach so far has been to use nested HBox and VBox widgets to compose your layout, which can make creating complex applications a tedious task. We now have a more flexible solution: the layout templates, which just landed with the latest release of the ipywidgets package.

The power of CSS, the simplicity of Python

Layout templates are a set of predefined layouts that allow you to combine multiple widgets on a single screen and arrange them visually. They leverage the powerful CSS Grid Layout specification, which is supported on most current browsers (yes, we are looking at you IE).

While the CSS Grid properties were first introduced in ipywidgets 7.3, they were tricky to use as they were transparently reflecting the CSS Grid Spec API and required the knowledge of the CSS. The new layout templates of ipywidgets wrap the CSS properties with a pythonic interface and sensible defaults, so they never expose the user to the nasty CSS spec. However, they inherit all the advantages of the Grid being fully responsive (they adapt to the screen size) and super easy to use!

Comparing the Python code with the generated CSS layout.

Application-like UIs in Jupyter

AppLayout consists of a header, two side panes, a central pane, and a footer.

If you want to create a simple application-like layout, you can use AppLayout, which consists of a header, a footer, two side panes, and a central pane. You can create the layout and populate it with widgets in a single command:

AppLayout(header=header,
          left_sidebar=prev_button,
          center=image,
          right_sidebar=next_button,
          footer=footer,
          grid_gap='20px',
          justify_items='center',
          align_items='center')

Importantly, if your application does not need all the panes defined by AppLayout, the layout has also some sensible defaults so that it can automatically merge widget locations that were not assigned.

Widgets on a grid

GridspecLayout places widgets on a rectangular grid. A single widget can span several rows or columns (or both).

If you require more flexibility to arrange widgets, you can also try GridLayout. First, you define the dimensions of a rectangular grid. Then you can place widgets on the grid either in a single cell of the grid or spanning several rows or columns (or both). This is easily achieved using the same slice-based API that you already use to select items from a NumPy array (or Python lists). If you already know matplotlib’s GridSpec feature, the syntax may look familiar:

# create a 10x2 grid layout
grid = GridspecLayout(10, 2)

# fill it in with widgets
grid[:, 0] = map
grid[0, 1] = zoom_slider
grid[1, 1] = basemap_selector
grid[2:, 1] = fig

# set the widget properties
grid[:, 0].layout.height = 'auto'

Style me up

The layouts are very configurable and can be easily tuned to the needs of your application. To change the sizes of the layout and the grid intervals, you can use style attributes, such as height , width, and gap-size options:

AppLayout(grid_gap='20px',
          height="200px",
          width="50%")

The size units are directly inherited from the CSS standard. More examples of style attributes can be found in the documentation.

So please go ahead and install the pre-release of ipywidgets that includes this new feature (pip install --upgrade ipywidgets) and take the new layout templates for a spin. We are looking forward to your feedback!

Acknowledgments

The author is a seasoned Python developer and a data scientist. He loves contributing to open source software; among others he is the creator and maintainer of the svgutils library.

The development of the ipywidgets layout templates was kindly supported by QuantStack.

Authoring Custom Jupyter Widgets

2018-03-05T12:12:00+00:00

Guest post authored by Olivier Borderies, Olivier Coudray, and Pierre Marion

Jupyter interactive widgets enhance the notebook experience by allowing users to create graphical user interfaces. They enable richer interaction with the data and computing resources.

While the base ipywidgets library comes with a number of controls such as sliders, buttons, and dropdowns, it is in fact much more than a collection of basic controls: it is the foundation of a framework upon which one can build arbitrarily complex interactions.

Examples of custom widget libraries built upon the foundational package are

bqplot, a d3-Jupyter bridge, and a 2-D plotting library following the constructs of the Grammar of Graphics,
ipyleaflet, a leaflet-Jupyter bridge enabling maps visualization in the Jupyter notebook,
pythreejs, a 3-D visualization library bringing the functionalities of Three.js into the Jupyter notebook,
ipyvolume, a 3-D plotting library also based on Three.js enabling volume rendering, quiver plots and much more.

Jupyter Widgets, a Bridge Between Two Continents

Jupyter widgets provide a means to bridge the kernel and the rich ecosystem of JavaScript visualization libraries for the web browser. It is an amazing opportunity for scientific developers to use all these resources in their language of choice.

This article is meant to serve as a guide for developers interested in authoring a custom widget library and bridge the gap between the basic examples of the official documentation and fully-fledged visualization libraries like the ones listed above.

A number of resources are provided alongside the article, including the complete source code of the examples, notebooks, and Binder links.

In this post, we focus on the Python back-end, even though dozens of Jupyter kernels exist. The Python kernel is the reference implementation of the Jupyter protocol and remains the most featureful. We should also mention QuantStack’s Xeus, a native C++ implementation of Jupyter kernel protocol, which supports interactive widgets. Xeus is used as the foundation for the support of Jupyter widgets for the R and C++ kernels.

Xeus: C++ implementation of Jupyter kernel protocol

A Hands-On Guide

While the Jupyter community is thriving, and we start seeing a growth in the number of custom widget libraries as well. Although the learning curve from the examples of the official Jupyter documentation to authoring state-of-the-art libraries like the ones listed above is steep and may be intimidating.

We started on this path a few months ago and benefited from guidance from core Jupyter developers along the way. Now, we would like to share the lessons learned. We hope this will help turn this mountain trail into a new silk road!

Let us start with the ‘Hello World’ example widget from the ipywidgets documentation, before moving on to more advanced use cases.

1 — Improving on the Hello-World Example from the Documentation

This section is derived from the ipywidgets documentation. The code snippets are CC-0 licensed.

The idea behind Jupyter widgets is to enable a bi-directional communication channel between the kernel (back-end) and the JavaScript front-end. In Python, widgets are special objects which are automatically synchronized with a counterpart object in the JavaScript front-end. In the back-end, the change events are handled by the traitlets package, which implements the observer pattern, while on the JavaScript side, this is done with the Backbone.js library.

The front-end implementation follows the MVC (Model View Controller) pattern. This allows the rendering of the same widget in multiple cell outputs, where all views share the same model, analogous to printing out a string variable multiple times.

The official documentation includes a Hello-World example widget, which offers an example of synchronization from Python to JavaScript, but not the other way around. Our jupyter-widget-hello-world-binder example provides a slightly more advanced version of it which demonstrates the bi-directional communication between the Python kernel and the JavaScript front-end. You can experiment with this widget on Binder or simply check out the example notebook with nbviewer.

Let us briefly present the main aspects of the implementation.

The JavaScript front-end defines a custom view by extending the base DOMWidgetView class from the base package:

var HelloView = widgets.DOMWidgetView.extend({
        render: function() {
            this.value_changed();
            this.model.on('change:value', this.value_changed, this);
        },

        value_changed: function() {
            this.el.textContent = this.model.get('value');
        }
    });

The Python back-end extends the corresponding base class from the ipywidgets package:

class HelloWidget(widgets.DOMWidget):
    _view_name = Unicode('HelloView').tag(sync=True)
    _view_module = Unicode('hello').tag(sync=True)
    _view_module_version = Unicode('0.1.0').tag(sync=True)

    value = Unicode('Hello World!').tag(sync=True)

The value attribute get synchronized between the back-end and the front-end.

The value_changed callback, which changes the HTML representation of the widget is attached to changes of the value property with the line:

this.model.on('change:value', this.value_changed, this);

In the Hello-World example from the documentation, there is no way to change the JavaScript value from the notebook front-end. We have added this feature in order to illustrate the bi-directional synchronization between JavaScript and Python. The idea is to trigger an event in the browser which will update the JavaScript model and then automatically - that’s the magic of ipywidgets - the Python back-end. These additional lines trigger the model update:

// update the JavasScript model
this.model.set('value', formElement[0].value);

// sync with Python
this.touch();

Conversely, when changing the value from the Python kernel the corresponding JavaScript value gets updated, as explained above.

Check out the jupyter-widget-hello-world-binder repo for more information. The notebook includes additional details and comments.

2 — First Example Involving Bi-Directional Communication

In the previous section, widgets were entirely defined in the notebook. We now show how to move the implementation outside of the notebook document and produce a proper installable package.

To help you create your own custom widget, the Jupyter team provides a cookiecutter template, producing a custom Jupyter widget library containing all the boilerplate for packaging. The cookiecutter is initialized with the hello-world widget from the documentation.

We used the widget cookiecutter to put the hello-world widget presented in the previous section into a well-organized GitHub repository. It contains

the Python part in the first_widget folder
the JavaScript part in the js folder.

The README provides detailed instructions to install the package, together with information about how to enable the Jupyter extension, and tips for custom widget authors. It delves into the technical details a bit more than this overview blog post.

Now that the basics of two-way synchronization are covered, you can create arbitrarily complex widgets! The key is to identify the data you would like to synchronize between the front-end and the back-end. Then you can set up the events that will update this data when a change is detected using the building blocks above.

Now you can ‘widget-ify’ any JavaScript library!

2.2 — Barebones `setup.py`

The setup.py described in the official documentation tries to automate many of the build steps, at the cost of readability. Fortunately, packaging Jupyter widgets will work with the bare-bones setup.py we provide.

The gain is a clearer, lighter (~100 less lines) setup.py, giving you a better understanding of what is happening.
The drawback is that you need one extra step to install the widget from source.

# Example: d3-slider
$ git clone https://gitlab.com/oscar6echo/jupyter-widget-d3-slider.git
$ cd js
$ npm install
$ cd ..
$ pip install -e .

# Extra line `jupyter nbextension install`
$ jupyter nbextension install --py --symlink --sys-prefix jupyter_widget_d3_slider
$ jupyter nbextension enable --py --sys-prefix jupyter_widget_d3_slider

More importantly we thought that it was clearer to keep the build steps of the Python and JavaScript packages separated. Both build processes are well documented, making the steps easier to follow. Finally, the inclusion of compiled JavaScript bundles in the Python package, is more explicit.

2.3 — Side Note: Naming Conventions

Naming conventions for Python packages are covered by PEP8. They can be a bit tricky in the case of 2-words names like “first-widget”. Where to use underscore (_) or hyphen (-) ? Typically “-” is used in GitHub repositories, and URLs and JavaScript while any folder or file in a Python module can only contain “_”. In the case of a Jupyter widget there is an extra attention point: in the setup.py file, the data_files argument in the setup function is a list of tuples. For each, the first element (representing a path in the filesystem) contains “-” as it relates to JavaScript code while the paths in the second contain “_” as they represent paths in the Python package. For a full example see the first-widget repo and the detailed README.

3 — Increasingly Complex Widgets

We made the following three widgets, gradually adding complexity. The first two examples are meant as educational examples:

d3-slider, a d3.js-based slider,
drawing-pad, a 2-D drawing pad,

We hope that the last example will become more than a demonstration:

ipypivot, a visual Pivot Table UI

In each case, the GitHub repository includes a demo notebook and the required boilerplate for Binder.

3.1 — d3-slider

This custom d3-slider widget wraps a simple custom slider based on the fantastic d3.js library. You can run and try it on the Binder repo or watch it on nbviewer.

d3-slider widget

To install:

$ pip install jupyter_widget_d3_slider

3.2 — drawing-pad

This small drawing pad app, is inspired from this codepen. You can run and try it on the Binder repo or watch it on nbviewer.

drawing pad widget

To install:

$ pip install jupyter-drawing-pad

3.3 — ipypivot

The ipypivot widget, wraps the convenient PivotTable.js library. You can run and try it on the binder repo or watch it on nbviewer.

ipypivot widget

To install:

$ pip install ipypivot

$ conda install -c conda-forge ipypivot

NOTE: The PivotUI widget is a combo of a custom widget and core widgets. This modular approach is more flexible (and looks nicer) but the same features can be made in a single custom widget containing extra buttons and display fields. The alt branch of the repo contains this version.

3.4 — Including JavaScript Callbacks

The ipypivot widget is an example of a widget that transparently wraps a JavaScript library. Transparent in the sense that all parameters of the JavaScript API are exposed, including functions, which are exposed in the form of strings on the Python side. In Python, JavaScript functions can only be strings, so there is an eval() to convert them to actual JavaScript functions.

The benefit is that all the functionalities of the JS libraries are exposed to the Python users with a very thin API. Developers can ‘widget-ify’ a large array of interesting libraries, thereby boosting the productivity of a Jupyter notebook user.

The downside is naturally the security concerns of enabling arbitrary JavaScript code to be injected by the notebook users. It is less a concern in the context of notebooks being shared within a small team of coworkers.

We are currently exploring means to execute the user-provided arbitrary JavaScript function in a sandboxed fashion, for example using the iframe srcdoc field (Cf. this repo for an example, though not in a Jupyter widget context) and messages can be sent back and forth between the main page and an iframe with the Window.postMessage function (see this gist for a bare bones example).

3.5 — Enabling Jupyter Widgets By Default

The jupyter nbextension enable command, arguably cumbersome, has become unnecessary as Jupyter widgets can be enabled by default from notebook version 5.3 (included). See this PR.

In order to be future-proof, all the widgets in this article include the file which triggers this ‘automatic enable’, and require notebook >= 5.3. Thus the pip-installation of our widgets is a one-line command. However, in dev mode, you still need to install and enable the notebook example (see section 3.1 for an example).

If you are working with an older version of notebook (run jupyter notebook --version to check), you will have to run the following command after pip-installing a widget:

$ jupyter nbextension enable --py --sys-prefix name_of_the_widget

4 — Packaging and Publishing

4.1 — PyPI and npm

If you have followed the “best practices” so far, packaging shouldn’t be an issue. Indeed, the cookiecutter provides a template of an easily-packageable widget.

Once your package is ready, you can publish it on:

PyPI for the package to be pip-installable
npmjs for the JavaScript extension, which is necessary to use the widget as a standalone application (outside of the notebook), render it with nbviewer, and also in the JupyterLab context.

To do so, you can follow these instructions in the documentation of first-widget.

4.2 — conda-forge

Conda has several advantages over pip:

It is a general-purpose package manager, which allows for non-python dependencies.
Unlike pip, it also has a real dependency solver, which prevents breaking your environments when updating a single package.
It allows creating virtual environments to isolate your projects.
It allows for one-line installation of Jupyter extension, including the enabling of the extension as a “post-link” script (temporary advantage: see the previous section).

Conda packages are available on different channels. The default channel is administrated by Anaconda Inc. The usually recommended channel to upload open source projects is conda-forge, as this article from Anaconda announces. To add this channel to your conda configuration, run the following command:

conda config --add channels conda-forge

Several steps are needed to publish a package on conda forge, using a so-called ‘recipe’:

writing the recipe, which describes how to build the package along with the dependencies required for building and running it
testing the recipe
publishing the package on the conda-forge GitHub by forking their staged-recipes repo
maintaining the package

The conda doc and the conda-forge doc are very clear and give you much more detailed information about this subject. If you do not want to read the full doc, and jump straight to the necessary information for publishing a new package, you may want to have a look at our first-widget repo. The README contains a section describing the publishing process for conda-forge.

4.3 — Automatic Push Script

The sequence of steps to update the version of a Jupyter widget and do all the pushing to the various repositories is quite long.

run npm prepare to build the js in folder static/
Update version in __meta__.py
push package to pypi
compute package sha256
tag repo with version
push to GitHub / GitLab / Bitbucket including tag
push js to npmjs
push to conda-forge (which includes sha256 hash)

If you want to automate the process we advise to have a look at Maarten Breddels’ releash package (release with relish :-) ), and how it is used in the context of ipyvolume and ipysheet.

4.4 — Binder and nbviewer

nbviewer and Binder are two fantastic tools to share both static and live notebooks.

nbviewer requires a URL to a valid notebook JSON file — typically hosted on GitHub/GitLab. To make widgets render in nbviewer, you need (1) to make the JavaScript package for your widget available on npm, (2) to run the notebook with the corresponding JavaScript extension (with the same version), and (3) to save the notebook widget state (in the ‘Widgets’ tab) before pushing it to GitHub / GitLab.
Binder requires a URL to a GitHub repository containing notebooks and a manifest of the dependencies required to run this notebook, which is used to produce a Docker image including all the resources to run the notebook. Check out the mybinder.org documentation to know how exactly to make use of it. Another resource is the BinderHub documentation if you want to host your own deployment of Binder. Either way we also highly recommend the article Binder 2.0, a Tech Guide.

5 — Conclusion

Hopefully you will have learned something reading this article. We believe in the potential of Jupyter widgets and hope that this intermediate-level article will help getting more people involved in the development of the ecosystem.

Note: This article only covers the case of the classic Jupyter notebook. The integration with JupyterLab will be covered in a future article!

If you find bugs or are interested in improving the example widgets presented here, please do not hesitate contact the authors or open a pull request!

About the Authors

Alphabetical order:

Olivier Borderies, Société Générale
Olivier Coudray, Student at École Polytechnique
Pierre Marion, Student at École Polytechnique

The software presented in this post was built upon the work of a large number of people including the Jupyter team. We are especially grateful to Sylvain Corlay, Jason Grout, Paul Ivanov, and Steven Silvester from the Jupyter Steering Council, as well as Maarten Breddels and Pascal Bugnion.

Release of ipywidgets 6.0

2017-03-01T15:44:00+00:00

We are pleased to announce the release of ipywidgets 6.0, the Jupyter interactive widget library. Jupyter interactive widgets enable building simple GUIs in the Jupyter notebook.

ipywidgets 6.0 is a major release of the project. In this release, we closed 197 issues and 309 pull requests with 732 commits.

Installation

Using conda:

conda install ipywidgets -c conda-forge

Using pip:

pip install ipywidgets
jupyter nbextension enable --py --sys-prefix widgetsnbextension

What’s new in ipywidgets 6.0?

Custom widget styling

In addition to the existing Widget.layout attribute, which enables the specification of layout-related css properties for the top-most DOM element of a widget, we added a new Widget.style attribute. This attribute enables custom styling of various widget types (such as Button.style.button_color).

The top-level styling properties that were deprecated in ipywidgets 5.0 have been removed.

Using widgets outside of the notebook

Another change in 6.0 is the ability to render Jupyter interactive widgets outside of the notebook:

Widgets can be rendered in Sphinx documentation, either with the jupyter-sphinx extension or the nbsphinx notebook converter.
Widgets now render on nbviewer.
Jupyter interactive widgets can be embedded into static web sites, such as http://jupyter.org/widgets.

Custom widget libraries built upon ipywidgets 6.0 can also take advantage of these features.

This feature required the formal specification of a mime type for Jupyter interactive widgets, which is now contained in the new jupyter-widgets-schema npm package.

Redesign of the core widgets

The widgets provided with the base Jupyter widget libraries have gone through a major re-design.

We also migrated from the less CSS preprocessor to the use of css variables. In addition to the main benefits of adopting web standards, we take advantage of css variables defined in JupyterLab to style the interactive widgets consistent with the environment.

Migration to Typescript

The jupyter-js-widgets JavaScript package, which is the front-end component of ipywidgets, has been completely refactored and migrated to the Typescript programming language. We also adopted the PhosphorJS JavaScript framework, which is at the foundation of the JupyterLab project, for better layout capability and integration with JupyterLab.

Credits

This release has been a team effort of a large number of contributors. We would like to thank the following 31 people who contributed, and especially the 14 people who contributed for the first time in this release.

Contributors to this release (alphabetical order):

Afshin Darian (first contribution)
Adam Chainz (first contribution)
Benjamin Ragan-Kelley
Brian Granger
Cameron Oelsen (first contribution)
Carol Willing
Dave Willmer
denfromufa
Giles Weaver (first contribution)
Gino Bustelo
Grant Nestor (first contribution)
Jason Grout
Javier Pedemonte
Jeff (first contribution)
Jeroen Demeyer
Jonathan Frederic
Justin McCandless (first contribution)
Ludwig Schmidt-Hackenberg (first contribution)
Maarten Breddels (first contribution)
Martin Renou (first contribution)
Matthew Craig
Matthias Bussonnier
Michael Pacer (first contribution)
Oliver Evans (first contribution)
Paul Ivanov
Philipp Rudiger (first contribution)
Srinivas Kumar Sunkara (first contribution)
Steven Silvester
stonebig (first contribution)
Thomas Kluyver
Sylvain Corlay
Yoshiki Vázquez Baeza

ipywidget security release

2016-09-26T23:37:00+00:00

Hello Jovyan,

A version of ipywidget has been released, which fixes important security issues. Please upgrade ipywidgets as soon as you can:

$ pip install ipywidgets --upgrade

Please do so in all your environments.

More details follow. We requested a CVE number and were asked to wait before any public disclosure of the vulnerability. As we have now been delaying the disclosure for over a resonable time, and we’re still waiting for the CVE number, we decided to still disclose the vulnerability. This post will be updated once/if a CVE number is made available.

[Update Dec 15, 2016]

A CVE number cannot be assigned for lack of sufficient information. No explanation of what more is needed was provided.

Description

ipywidgets version 5.1.5 (widgetsnbextension 1.2.3) fixes a security vulnerability (CVE-PENDING) which affects the usage of ipywidgets in conjunction with the Jupyter Notebook.

Affected versions

ipywidgets version 5.0.0 ≤ V ≤ 5.1.4 (widgetsnbextension < 1.2.3).

Only users who installed ipywidgets using pip or from source on the GitHub repository are affected.

Anaconda users are unaffected because the vulnerable version of ipywidget has never been released to the default conda channel.

Resolution

We released ipywidgets version 5.1.5 (widgetsnbextension version 1.2.3).

You can check whether your system is affected by running the following command from a Python or IPython prompt:

>>> from distutils.version import LooseVersion as V
>>> import ipywidgets
>>> if V('5.0.0') <= V(ipywidgets.__version__) < V('5.1.5'):
        print("Upgrade ipywidgets to 5.1.5")

If your system is vulnerable, you will see the following output:

Upgrade ipywidgets to 5.1.5

If your system is vulnerable please upgrade to ipywidgets version 5.1.5. Use the following command to install:

$ pip install "ipywidgets>=5.1.5"

$ conda install "ipywidgets>=5.1.5"

Technical details

The vulnerability was discovered following an investigation of a potential vulnerability reported by Brian Granger to the ipython-security mailing list (security@ipython.org) on May 5.

The reason for such behavior was determined on May 5 by Matthias Bussonnier.
A fix was proposed written and reviewed, then merged into the development branch on May 20, and a non vulnerable version released on May 25.

A widget snapshotting feature introduced in ipywidgets 5.0.0 allowed untrusted javascript code to execute in an untrusted notebook on loading and saving of a notebook. A well crafted notebook could execute arbitrary code with the rights of the current user in the context of the page, the notebook server, and available kernels.

We recommend immediate upgrade of the ipywidgets package.

There is no simple configuration option that could mitigate the system for vulnerability. The user must upgrade to ipywidget version 5.1.5 or downgrade to 4.x.

Future Plan

The security issue resulted from the seemingly harmless combination of calls:

json = cell.get_json()
json = update_json(json)
cell.clear_output()
cell.from_json(json)

The clear_output() method has as a consequence to mark the cell as trusted (as it has no output that can potentially execute javascript). This is followed by the next call which can trigger JavaScript execution in the page context.

We plan on improving the notebook API so that clear_output() does not change the trusted status of a cell (or a notebook), to prevent mistakes like this from having security consequences. This will lead to the slight behavior change that an empty cell with no output can be untrusted.

Doing better next time

We learned that we are not completely ready for fast release of security fixes. The time from vulnerability discovery to available fix and release could have been better. The announcement was delayed while waiting for a CVE number which is still not there. We will consider a sorter timescale to publication even if we don’t get assigned a CVE number quickly. The standard seem to be 90 days from security vulnerability report, we might end up selecting this as well.

We encourage users who find possible security issues to notify security@ipython.org.

Thanks!

ipywidgets 5.0

2016-04-23T02:48:00+00:00

On April 19, 2016, we released ipywidgets 5.0. The ipywidgets package provides interactive HTML & JavaScript widgets (such as sliders, checkboxes, text boxes, charts, and more) for the Jupyter architecture that combine front-end controls coupled to a Jupyter kernel. It also ships a Python implementation of the kernel-side APIs to be used by the IPython kernel.

Altogether, 17 authors contributed to 205 pull requests to make this release.

This release features several major changes and a myriad of smaller changes and bugfixes.

The main change in this release is the split and refactoring of the old package into two packages: a pure Javascript package, jupyter-js-widgets, published on npm (version 1.0), at https://www.npmjs.com/package/jupyter-js-widgets the Python backend, ipywidgets.

This separation decouples widget display views from language specific kernel operations of a widget. Kernel authors benefit from being able to more easily implement backends for other language kernels, like R, Julia, Ocaml or Haskell, while at the same time using a stable target version of jupyter-js-widgets. We intend to follow the semantic versioning convention for future releases of jupyter-js-widgets. A runtime compatibility check between frontend and backend is also implemented for user convenience.

The stabilization of Javascript APIs in this release provides a path for custom widget authors to update efficiently to future versions.

Another important new feature, use of Jupyter widgets outside of the notebook context, gives new possibilities for information control and display. Live interactive widgets can now be embedded into static web pages or blogs by inserting an html snippet containing the serialized widget state. This also works with custom widget libraries. See http://jupyter.org/embed-jupyter-widgets.html.

A major change to the Javascript widget code will affect authors of custom Javascript widgets. The Javascript widget code in ipywidgets 5.0 is backward incompatible with previous releases. Three popular custom widget libraries (pythreejs, bqplot, and ipyleaflet) are being released today with the required updates and changes. We can assist authors of Javascript custom widget libraries to make the changes required to migrate their libraries to this new version. Python APIs continue to be backward compatible.

Smaller changes in this release include the addition of a new ‘selection slider’ and making the layout of interactive widgets on the page much easier.

A more detailed document on the changes is available here:https://github.com/ipython/ipywidgets/wiki/ipywidgets-5.0-Release-Document

Using this release of ipywidgets requires a Jupyter notebook 4.2 installation which uses the notebook’s new nbextension installation and enabling features. If you have an older version of the notebook and you upgrade ipywidgets, the ipywidgets upgrade will also install for you an updated version of the notebook.

Thank you to the entire Jupyter and IPython team for making this a possibility. An extra big thank you to Sylvain Corlay for working many late hours and weekends to make this happen.

Jupyter Blog - widgets

ipydatagrid is now part of Project Jupyter

What is ipydatagrid?

Key Features

The transfer to Project Jupyter

Bloomberg’s contribution to Project Jupyter

Make your Pandas or Polars DataFrames Interactive with ITables 2.0

How to use ITables, and what you get

A brief history of ITables

My favorite DataTables Extensions

Download your data!

Cascade search

Search builder

Downsampling

Acknowledgments

anywidget: Jupyter Widgets Made Easy

Why making widgets is hard

A universal widget adapter

A realistic example

Modern web development meets Jupyter

Try it out!

Jupyter Community Workshop: The Future of Jupyter Widgets

Jupyter Games

Motivation

Mini-Games

Box2D

Box2D Debug Draw

DebugDraw

LiquidFun

More than just Games

Box2D Python

pybox2d

pyb2d

Jupyter Box2D Integration: Requirements

Ipycanvas, Ipywidgets, Ipyevents

Ipycanvas

An Ipycanvas-based DebugDraw:

Handling events in Jupyter:

Adding Buttons:

Putting it all together

Billiard:

Angry Shapes:

World of Goo homage:

Rocket:

Compatibility

Caveats

Outlook / Sneak preview

Acknowledgments

About the author

Build a Jupyter Widget with React and TypeScript

Setup

Interacting with the Widget

Building a Color Picker

Resources

A Curiously Recurring Widget Library

Using the RAII pattern for a widget library

Static polymorphism and the CRTP pattern

CRTP in xwidgets — closing the recursion

Precompilation and binary size optimization

Xproperty: an implementation of the observer pattern

Method chaining for widget initialization

Building upon xwidgets

C++ should allow overloading the dot operator

Try it online!

About the author

Interactive Graph Visualization in Jupyter with ipycytoscape

Current state

Try it online!

Installation

About the author

Acknowledgements

ipycanvas: A Python Canvas for Jupyter

ipycanvas: Exposing the Canvas API to IPython

Documentation

Github repository

Try it online!

Installation

About the author

Introducing templates for Jupyter widgets layouts

The power of CSS, the simplicity of Python

2.2 — Barebones `setup.py`