.. author:: Andrew Seier

Discussion

• development branches:
• related pull requests:

This MEP aims at adding a serializableController objects to act as anArtist managers. Users would then communicate changes to anArtist via aController. In this way, functionality of theController objects may be added incrementally since eachArtist is still responsible for drawing everything. The goal is to create an API that is usable both by graphing libraries requiring high-level descriptions of figures and libraries requiring low-level interpretations.

Matplotlib is a core plotting engine with an API that many users already understand. It's difficult/impossible for other graphing libraries to (1) get a complete figure description, (2) output raw data from the figure object as the user has provided it, (3) understand the semantics of the figure objects without heuristics, and (4) give matplotlib a complete figure description to visualize. In addition, because anArtist has no conception of its own semantics within the figure, it's difficult to interact with them in a natural way.

In this sense, matplotlib will adopt a standard Model-View-Controller (MVC) framework. TheModel will be the user defined data, style, and semantics. TheViews are the ensemble of each individualArtist, which are responsible for producing the final image based on themodel. TheController will be theController object managing its set ofArtist objects.

TheController must be able to export the information that it's carrying about the figure on command, perhaps via ato_json method or similar. Because it would be extremely extraneous to duplicate all of the information in the model with the controller, only user-specified information (data + style) are explicitly kept. If a user wants more information (defaults) from the view/model, it should be able to query for it.

• This might be annoying to do, non-specified kwargs are pulled from the rcParams object which is in turn created from reading a user specified file and can be dynamically changed at run time. I suppose we could keep a dict of default defaults and compare against that. Not clear how this will interact with the style sheetMEP26 - @tacaswell

Additional Notes:

• Theraw data does not necessarily need to be alist,ndarray, etc. Rather, it can more abstractly just have a method to yield data when needed.
• Because theController will contain extra information that users may not want to keep around, it shouldnot be created by default. You should be able to both (a) instantiate aController with a figure and (b) build a figure with aController.

Use Cases:

• Export all necessary information to recreate a matplotlib representation as json
• Serializing a matplotlib figure, saving it, and being able to rerun later.
• Any other source sending an appropriately formatted representation to matplotlib to open

Here are some examples of what the controllers should be able to do.

1. Instantiate a matplotlib figure from a serialized representation (e.g., JSON):

   import jsonfrom matplotlib.controllers import Controllerwith open('my_figure') as f:    o = json.load(f)c = Controller(o)fig = c.figure

2. Manage artists from the controller (e.g., Line2D):

   # not really sure how this should lookc.axes[0].lines[0].color = 'b'# ?

3. Export serializable figure representation:

   o = c.to_json()# or... we should be able to throw a figure object in there tooo = Controller.to_json(mpl_fig)

1. Create baseController objects that are able to manageArtist objects (e.g.,Hist)

   Comments:

   • initialization should happen via unpacking**, so we need a copy of call signature parameter for theArtist we're ultimately trying to control. Unfortunate hard-coded repetition...
   • should the additional**kwargs accepted by eachArtist be tracked at theController
   • how does aController know which artist belongs where? E.g., do we need to passaxes references?

   Progress:

   • A simple NB demonstrating some functionality forLine2DController objects:http://nbviewer.ipython.org/gist/theengineear/f0aa8d79f64325e767c0

2. Write in protocols for theController toupdate the model.

   Comments:

   • how should containers be dealt with? E.g., what happens to old patches when we re-bin a histogram?
   • in the link from (1), the old line is completely destroyed and redrawn, what if something is referencing it?

3. Create method by which a json object can be assembled from theControllers

4. Deal with serializing the unserializable aspects of a figure (e.g., non-affine transforms?)

5. Be able to instantiate from a serialized representation

6. Reimplement the existing pyplot and Axes method, e.g.pyplot.hist andAxes.hist in terms of the new controller class.

> @theengineer: in #2 above, what do you mean byget updates from eachArtist?

^ Yup. TheControllershouldn't need to get updated. This just happens in #3. Delete comments when you see this.

• pickling will change
• non-affine transformations will require a defined pickling method

PR #3150 suggested adding semantics by parasitically attaching extra containers to axes objects. This is a more complete solution with what should be a more developed/flexible/powerful framework.