So far so good from my end. 👍

One thing that caught my eyes though: could patterns like

from IPython.html.widgets import IntSliderWidget
from plotly.widgets import Graph
import plotly.plotly as py

from IPython.display import display

# ....

slider = IntSliderWidget(min=0,max=20,step=0.1)
slider.on_trait_change(make_cagraph = Graph(py.plot([{}], filename='taylor series widget', auto_open=False))llback(slider, graph), 'value')

display(slider)
display(graph)

be abstracted a little bit more ?

Maybe have something like:

from plotly.widgets import Graph, Slider

graph = Graph(py.plot([{}], filename='taylor series widget', auto_open=False))

slider = Slider(min=0, max=20, step=0.1)
slider.on_trait_change(make_callback(slder, graph), 'value')
slider.display()
graph.display()

would make things easier for users that never played around with IPython widgets before.

@chriddyp , so slick! Gonna take a peek at #170 first, then I'll play around with this!

Alright, digging in :)

Where/how does the restyle/relayout call get sent to plotly? Is this what's happening?

(1) User calls g.restyle() in IPython.
(2) That gets sent to IPython backend and handled in JS.
(3) The backend JS code communicates with Plotly?

Can we (should we) change relayout and restyle to expose a simpler API for folks?

Say, using update or something on a Figure object? Would that be possible?

So, instead of restyle and relayout, users can do things like:

fig['layout'].update(title='new title')

Under the hood, we can still call relayout and restyle, but we might want to consider some convenience functions.

@theengineear re #171 (comment) - on (3) yeah, the JS code communicates to the embedded Plotly iframe through the postMessage protocol and listens to messages sent from the events in the iframe on the window event here: https://github.com/plotly/python-api/pull/171/files#diff-5283ffa0a4b258e3ffc8722baffb9912R84. So, this is entirely client-side.

@theengineear re #171 (comment), we'll want to keep the Figure object isolated from the GraphWidget object because I want the GraphWidget parameterized by a (any) plotly embed URL.

we could have something more gnarly like a Graph object which has a Figure object as a parameter. We could pass the figure object with postMessage from the iFrame over to the client keep Graph.figure and the embedded iframe in sync.

This sort of feels like moving towards @BRONSOLO 's plotlyfigure object in matlab, which basically had everything bound to it, like fig.png, fig.url, fig.data, fig.layout, fig.filename.

• Would you save the graph with py.plot(graph.figure) or with graph.save(filename)
• Would streaming be incorporated into this graph object? graph.update({'x': 1, 'y': 1}, streaming=True)

Yikes!

@chriddyp , is there a way to add a completely new trace to a graph? I naively tried to restyle a blank graph, but realized that that's not workable.

Along these lines, we could also offer to just serve up a blank iframe for people to build on. Thoughts?

@theengineear there isn't right now, which is pretty annoying!

This is something that needs to be built into the js, yeah? Same as the remove-trace?

yeah exactly

@chriddyp , i added in the framework for add/delete/move traces (it's not working yet because that PR isn't pulled into master on streambed) the syntax may also change, i opened up a discussion about how we format postMessage here: https://github.com/plotly/streambed/pull/1114#issuecomment-69295142

Also, this doesn't work for me and I'm confused why :(

import random
import plotly.plotly as py
from plotly.graph_objs import *
from plotly.widgets import Graph

plotly_url = py.plot([Scatter()], filename='blank', auto_open=False)
graph = Graph(plotly_url)

def click_handler(*args, **kwargs):
    graph.restyle({'y': [[random.random() for _ in range(10)]]}, traces=[0])  
graph.on_click(click_handler)

graph

Also, also, it's not clear in the docs, but can you remove a click handler once you assign it? or do they overwrite themselves?

Have you taken a peek as the dev-tools console for this stuff, btw? full of errors and warnings.

This is just a warning, but we could probably clean it up by sending a string instead of an object? Is that reasonable? Received message of type object from http://localhost:8888, expected a string

Not sure what to do about this one... it just happens a bunch of times and then eventually stops complaining an works: Failed to execute 'postMessage' on 'DOMWindow': The target origin provided ('https://plot.ly') does not match the recipient window's origin ('http://localhost:8888').

Another thing, I opened the dev tools initially to try and debug why pointing python at my local streambed wasn't working, which I haven't figured out--i thought i'd just ask :)

Is 'https://plot.ly' hardcoded for us in python, or in frontend js?

k, found where the 'https://plot.ly' was hiding in graphWidget.js

I'm going to pass that into graphWidget.js now, but I'm also going to need a reference from graph_widget.py. for now that means i need to import plotly.py (ew)...

This is exactly why we should really create a new session module that everyone can import and get the most updated versions of the info the user has setup for the current session.

@chriddyp , the above commit should fix communication with local plotly instances. This will seriously improve development when changes need to be made to plotly frontent js code and the python-api widget code.

NOTE (this is a little annoying... the iframe js code is cached so every time you do make a change, you need to clear your cache) took me a second to realize that earlier and thought I'd mention it here.

See #177 for the updates to this widgets branch.

Re: #171 (comment)

For graphJson, I'm thinking of somehow allowing an 'attributes' object that would just return the specified keys. For now, we can filter this in postMessage so that postMessage requests are stable, but eventually it will be better to make graphJson more flexible, but that might be a bigger refactor than i can do today.

Therefore:

// message for getting the *full* figure
{
    'task': 'getAttributes',
}

// message for getting certain attributes
{
    'task': 'getAttributes',
    'attributes': ['data[0].opacity', 'layout.title']
}

// message for getting defaults if user didn't specify
{
    'task': 'getAttributes',
    'useDefaults': True
}

// message for getting data only (no layout)
{
    'task': 'getAttributes',
    'attributes': ['data']
}

// message for getting layout only (no data)
{
    'task': 'getAttributes',
    'attributes': ['layout']
}

Something like this seem okay? There's already a postMessage getLayout, but I really think we can make this all into a single, very simple request under getAttributes or getGraph or whatever, i sorta like the former.

Nice NEWS file! ha, that was supposed to be in a different PR, lol @mkcor

to put it on record, we're going to go with the opposite logic, useDefaults --> ignoreDefaults

boom!

On Thu, Jan 22, 2015 at 5:34 PM, chriddyp [email protected] wrote:

Merged #171 #171.

—
Reply to this email directly or view it on GitHub
#171 (comment).