<h2><aclass="toc-backref" href="#id1" role="doc-backlink">Status</a><aclass="headerlink" href="#status" title="Permalink to this heading">#</a></h2>
<p><strong>Rejected</strong></p>
<p>This work is important, but this particular effort has stalled.</p>
</section>
<sectionid="branches-and-pull-requests">
<h2><aclass="toc-backref" href="#id2" role="doc-backlink">Branches and Pull requests</a><aclass="headerlink" href="#branches-and-pull-requests" title="Permalink to this heading">#</a></h2>
<ulclass="simple">
<li><p>development branches:</p></li>
<li><p>related pull requests:</p></li>
</ul>
</section>
<sectionid="abstract">
<h2><aclass="toc-backref" href="#id3" role="doc-backlink">Abstract</a><aclass="headerlink" href="#abstract" title="Permalink to this heading">#</a></h2>
<p>This MEP aims at adding a serializable <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code> objects to act
as an <codeclass="docutils literal notranslate"><spanclass="pre">Artist</span></code> managers. Users would then communicate changes to an
<codeclass="docutils literal notranslate"><spanclass="pre">Artist</span></code> via a <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code>. In this way, functionality of the
<codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code> objects may be added incrementally since each
<codeclass="docutils literal notranslate"><spanclass="pre">Artist</span></code> 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.</p>
</section>
<sectionid="detailed-description">
<h2><aclass="toc-backref" href="#id4" role="doc-backlink">Detailed description</a><aclass="headerlink" href="#detailed-description" title="Permalink to this heading">#</a></h2>
<p>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 an <codeclass="docutils literal notranslate"><spanclass="pre">Artist</span></code> has no conception of its own semantics
within the figure, it's difficult to interact with them in a natural
way.</p>
<p>In this sense, matplotlib will adopt a standard
Model-View-Controller (MVC) framework. The <em>Model</em> will be the user
defined data, style, and semantics. The <em>Views</em> are the ensemble of
each individual <codeclass="docutils literal notranslate"><spanclass="pre">Artist</span></code>, which are responsible for producing the
final image based on the <em>model</em>. The <em>Controller</em> will be the
<codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code> object managing its set of <codeclass="docutils literal notranslate"><spanclass="pre">Artist</span></code> objects.</p>
<p>The <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code> must be able to export the information that it's
carrying about the figure on command, perhaps via a <codeclass="docutils literal notranslate"><spanclass="pre">to_json</span></code> 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.</p>
<ulclass="simple">
<li><p>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 sheet
[[MEP26]] - @tacaswell</p></li>
</ul>
<p>Additional Notes:</p>
<ulclass="simple">
<li><p>The "raw data" does not necessarily need to be a <codeclass="docutils literal notranslate"><spanclass="pre">list</span></code>,
<codeclass="docutils literal notranslate"><spanclass="pre">ndarray</span></code>, etc. Rather, it can more abstractly just have a method
to yield data when needed.</p></li>
<li><p>Because the <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code> will contain extra information that users
may not want to keep around, it should <em>not</em> be created by
default. You should be able to both (a) instantiate a <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code>
with a figure and (b) build a figure with a <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code>.</p></li>
</ul>
<p>Use Cases:</p>
<ulclass="simple">
<li><p>Export all necessary informat</p></li>
<li><p>Serializing a matplotlib figure, saving it, and being able to rerun later.</p></li>
<li><p>Any other source sending an appropriately formatted representation to matplotlib to open</p></li>
</ul>
</section>
<sectionid="examples">
<h2><aclass="toc-backref" href="#id5" role="doc-backlink">Examples</a><aclass="headerlink" href="#examples" title="Permalink to this heading">#</a></h2>
<p>Here are some examples of what the controllers should be able to do.</p>
<olclass="arabic">
<li><p>Instantiate a matplotlib figure from a serialized representation (e.g., JSON):</p>
<h2><aclass="toc-backref" href="#id6" role="doc-backlink">Implementation</a><aclass="headerlink" href="#implementation" title="Permalink to this heading">#</a></h2>
<olclass="arabic">
<li><p>Create base <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code> objects that are able to manage
<li><p>initialization should happen via unpacking <codeclass="docutils literal notranslate"><spanclass="pre">**</span></code>, so we need a
copy of call signature parameter for the <codeclass="docutils literal notranslate"><spanclass="pre">Artist</span></code> we're
ultimately trying to control. Unfortunate hard-coded
repetition...</p></li>
<li><p>should the additional <codeclass="docutils literal notranslate"><spanclass="pre">**kwargs</span></code> accepted by each <codeclass="docutils literal notranslate"><spanclass="pre">Artist</span></code>
be tracked at the <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code></p></li>
<li><p>how does a <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code> know which artist belongs where? E.g.,
do we need to pass <codeclass="docutils literal notranslate"><spanclass="pre">axes</span></code> references?</p></li>
</ul>
<p>Progress:</p>
<ulclass="simple">
<li><p>A simple NB demonstrating some functionality for
<li><p>Write in protocols for the <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code> to <em>update</em> the model.</p>
<blockquote>
<div><p>Comments:</p>
<ulclass="simple">
<li><p>how should containers be dealt with? E.g., what happens to old
patches when we re-bin a histogram?</p></li>
<li><p>in the link from (1), the old line is completely destroyed and
redrawn, what if something is referencing it?</p></li>
</ul>
</div></blockquote>
</li>
<li><p>Create method by which a json object can be assembled from the
<li><p>Deal with serializing the unserializable aspects of a figure (e.g.,
non-affine transforms?)</p></li>
<li><p>Be able to instantiate from a serialized representation</p></li>
<li><p>Reimplement the existing pyplot and Axes method,
e.g. <codeclass="docutils literal notranslate"><spanclass="pre">pyplot.hist</span></code> and <codeclass="docutils literal notranslate"><spanclass="pre">Axes.hist</span></code> in terms of the new
controller class.</p></li>
</ol>
<p>> @theengineer: in #2 above, what do you mean by <em>get updates</em> from
each <codeclass="docutils literal notranslate"><spanclass="pre">Artist</span></code>?</p>
<p>^ Yup. The <codeclass="docutils literal notranslate"><spanclass="pre">Controller</span></code><em>shouldn't</em> need to get updated. This just
happens in #3. Delete comments when you see this.</p>
</section>
<sectionid="backward-compatibility">
<h2><aclass="toc-backref" href="#id7" role="doc-backlink">Backward compatibility</a><aclass="headerlink" href="#backward-compatibility" title="Permalink to this heading">#</a></h2>
<ulclass="simple">
<li><p>pickling will change</p></li>
<li><p>non-affine transformations will require a defined pickling method</p></li>
</ul>
</section>
<sectionid="alternatives">
<h2><aclass="toc-backref" href="#id8" role="doc-backlink">Alternatives</a><aclass="headerlink" href="#alternatives" title="Permalink to this heading">#</a></h2>
<p>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.</p>