You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This MEP aims at adding a serializable ``Controller`` objects to act as an ``Artist`` managers. Users would then communicate changes to an ``Artist`` via a ``Controller``. In this way, functionality of the ``Controller`` objects may be added incrementally since each ``Artist`` 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.
22
+
This MEP aims at adding a serializable ``Controller`` objects to act
23
+
as an ``Artist`` managers. Users would then communicate changes to an
24
+
``Artist`` via a ``Controller``. In this way, functionality of the
25
+
``Controller`` objects may be added incrementally since each
26
+
``Artist`` is still responsible for drawing everything. The goal is to
27
+
create an API that is usable both by graphing libraries requiring
28
+
high-level descriptions of figures and libraries requiring low-level
29
+
interpretations.
22
30
23
31
Detailed description
24
32
--------------------
25
33
26
-
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 ``Artist`` has no conception of its own semantics within the figure, it's difficult to interact with them in a natural way.
27
-
28
-
In this sense, matplotlib will adopt a standard Model-View-Controller (MVC) framework. The *Model* will be the user defined data, style, and semantics. The *Views* are the ensemble of each individual ``Artist``, which are responsible for producing the final image based on the *model*. The *Controller* will be the ``Controller`` object managing its set of ``Artist`` objects.
29
-
30
-
The ``Controller`` must be able to export the information that it's carrying about the figure on command, perhaps via a ``to_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.
31
-
32
-
- 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
34
+
Matplotlib is a core plotting engine with an API that many users
35
+
already understand. It's difficult/impossible for other graphing
36
+
libraries to (1) get a complete figure description, (2) output raw
37
+
data from the figure object as the user has provided it, (3)
38
+
understand the semantics of the figure objects without heuristics,
39
+
and (4) give matplotlib a complete figure description to visualize. In
40
+
addition, because an ``Artist`` has no conception of its own semantics
41
+
within the figure, it's difficult to interact with them in a natural
42
+
way.
43
+
44
+
In this sense, matplotlib will adopt a standard
45
+
Model-View-Controller (MVC) framework. The *Model* will be the user
46
+
defined data, style, and semantics. The *Views* are the ensemble of
47
+
each individual ``Artist``, which are responsible for producing the
48
+
final image based on the *model*. The *Controller* will be the
49
+
``Controller`` object managing its set of ``Artist`` objects.
50
+
51
+
The ``Controller`` must be able to export the information that it's
52
+
carrying about the figure on command, perhaps via a ``to_json`` method
53
+
or similar. Because it would be extremely extraneous to duplicate all
54
+
of the information in the model with the controller, only
55
+
user-specified information (data + style) are explicitly kept. If a
56
+
user wants more information (defaults) from the view/model, it should
57
+
be able to query for it.
58
+
59
+
- This might be annoying to do, non-specified kwargs are pulled from
60
+
the rcParams object which is in turn created from reading a user
61
+
specified file and can be dynamically changed at run time. I
62
+
suppose we could keep a dict of default defaults and compare against
63
+
that. Not clear how this will interact with the style sheet
64
+
[[MEP26]] - @tacaswell
33
65
34
66
Additional Notes:
35
67
36
-
* The `raw data` does not necessarily need to be a ``list``, ``ndarray``, etc. Rather, it can more abstractly just have a method to yield data when needed.
68
+
* The `raw data` does not necessarily need to be a ``list``,
69
+
``ndarray``, etc. Rather, it can more abstractly just have a method
70
+
to yield data when needed.
37
71
38
-
* Because the ``Controller`` will contain extra information that users may not want to keep around, it should *not* be created by default. You should be able to both (a) instantiate a ``Controller`` with a figure and (b) build a figure with a ``Controller``.
72
+
* Because the ``Controller`` will contain extra information that users
73
+
may not want to keep around, it should *not* be created by
74
+
default. You should be able to both (a) instantiate a ``Controller``
75
+
with a figure and (b) build a figure with a ``Controller``.
39
76
40
77
Use Cases:
41
78
42
79
* Export all necessary informat
80
+
* Serializing a matplotlib figure, saving it, and being able to rerun later.
81
+
* Any other source sending an appropriately formatted representation to matplotlib to open
82
+
83
+
Examples
84
+
--------
85
+
Here are some examples of what the controllers should be able to do.
86
+
87
+
1. Instantiate a matplotlib figure from a serialized representation (e.g., JSON): ::
88
+
89
+
import json
90
+
from matplotlib.controllers import Controller
91
+
with open('my_figure') as f:
92
+
o = json.load(f)
93
+
c = Controller(o)
94
+
fig = c.figure
95
+
96
+
2. Manage artists from the controller (e.g., Line2D): ::
97
+
98
+
# not really sure how this should look
99
+
c.axes[0].lines[0].color = 'b'
100
+
# ?
101
+
102
+
3. Export serializable figure representation: ::
103
+
104
+
o = c.to_json()
105
+
# or... we should be able to throw a figure object in there too
106
+
o = Controller.to_json(mpl_fig)
107
+
108
+
Implementation
109
+
--------------
110
+
111
+
1. Create base ``Controller`` objects that are able to manage
112
+
``Artist`` objects (e.g., ``Hist``)
113
+
114
+
Comments:
115
+
116
+
* initialization should happen via unpacking ``**``, so we need a
117
+
copy of call signature parameter for the ``Artist`` we're
118
+
ultimately trying to control. Unfortunate hard-coded
119
+
repetition...
120
+
* should the additional ``**kwargs`` accepted by each ``Artist``
121
+
be tracked at the ``Controller``
122
+
* how does a ``Controller`` know which artist belongs where? E.g.,
123
+
do we need to pass ``axes`` references?
124
+
125
+
Progress:
126
+
127
+
* A simple NB demonstrating some functionality for
0 commit comments