Skip to content

Matplotlib IPython Widget #4582

Closed
Closed

Description

@blink1073

I created a stub of a demo for a matplotlib interactive widget targeting IPython 3.2, for discussion.

https://gist.github.com/blink1073/0421d774677f8ffb98fe
http://nbviewer.ipython.org/gist/blink1073/0421d774677f8ffb98fe

Activity

  1. blink1073 commented on Jul 4, 2015

    @blink1073
    MemberAuthor
  2. added this to the milestone on Jul 31, 2015
  3. blink1073 commented on Aug 30, 2015

    @blink1073
    MemberAuthor

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

    I see two options:

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

    @tacaswell
    Member

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

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

  5. pelson commented on Sep 3, 2015

    @pelson
    Member

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

  6. blink1073 commented on Sep 3, 2015

    @blink1073
    MemberAuthor

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

  7. pelson commented on Sep 3, 2015

    @pelson
    Member

    I know that feeling 😄

  8. ellisonbg commented on Sep 6, 2015

    @ellisonbg

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

  9. fariza commented on Sep 22, 2015

    @fariza
    Member

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

  10. blink1073 commented on Sep 22, 2015

    @blink1073
    MemberAuthor

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

  11. OceanWolf commented on Sep 22, 2015

    @OceanWolf
    Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions