Thank you OceanWolf and Federico. I was previously unaware of the gid
property of Artists and the new ToolManager classes, and it looks like what
I have been doing is pretty similar to what is contained therein. You can
take a look at my progress here:
On Mon, Jun 6, 2016 at 5:34 AM, OceanWolf <juichenieder-nabb at yahoo.co.uk> > wrote:
Hi Daniel,
I like your ideas. As Fedrico said, the group part has already exists,
see http://matplotlib.org/examples/user_interfaces/toolmanager.html for
an example of this, the toolmanager part we still consider as experimental
until at least 2.1 when we hope to have gotten it working with all backends
together with http://matplotlib.org/devel/MEP/MEP27.html, refactoring
the FigureManager so as to decouple pyplot from the backends, a project
that I have been working on.
The other parts, http://matplotlib.org/devel/MEP/MEP26.html which looks
at creating Cascading Artist Style Sheets, based upon the CSS language spec
for websites. I don't think anyone has started working on this, and may
need some more definition and working out; then I started creating another
MEP to figure out how to refactor the Axes and related classes into a more
coherent and readably understandable structure, you can see the limited
progress i have made at defining the document here...
DOC: MEP to improve the Axes API by OceanWolf · Pull Request #5029 · matplotlib/matplotlib · GitHub I have a few more
ideas I want to put into this, just needing to find time to get back to it,
probably once we have the backend refactor finished.
Of course, matplotlib works as a fully opensource project, fully
collaborative, so any source code changes you would like to see, make them
in a fork, and PR them back to the matplotlib (or as I got started, forking
Federico's toolmanager fork, and PRing back to him and his PR before
merging into master, as part of MEP22). And of course, feel free to get
involved in any of this stuff if you like it, the more the merrier :).
Best,
OceanWolf
------------------------------
*From:* Federico Ariza <ariza.federico at gmail.com>
*To:* Daniel McNeela <daniel.mcneela at gmail.com>
*Cc:* matplotlib development list <matplotlib-devel at python.org>
*Sent:* Monday, 6 June 2016, 12:19
*Subject:* Re: [Matplotlib-devel] (no subject)
I have done similar things (hiding groups of artists) using the tool
manager and custom build tools.
In general I just use the gid property of each artist to keep track of
different groups and on trigger I hide a specific group.
Also I use it to pop-up an artist-styler to change colors, linestyle
etc...
It is indirect but allows to perform operations without touching base
classes.
I know this is not what you asked but hope it helps
Federico
On Jun 5, 2016 10:38 PM, "Daniel McNeela" <daniel.mcneela at gmail.com> >> wrote:
Basically I'm adding a "layer" construct to the Axes model that allows
users to define groups of Matplotlib artists that can be manipulated,
hidden, displayed, styled, etc. in tandem without affecting those artists
which are on other layers. It's sort of analogous to the way in which
layers work in Photoshop.
The issue with simply subclassing the Matplotlib Axes is that I want my
subclass to fully integrate with pyplot and other modules. For example, if
a user has my module imported and runs
>>> fig = plt.figure()
>>> subplot = plt.subplot(111)
I'd like for subplot to be an instance of my subclassed Axes rather than
of the default one provided by Matplotlib.
On Sun, Jun 5, 2016 at 5:31 PM, Thomas Caswell <tcaswell at gmail.com> >> wrote:
Simply sub-classing any of those classes in your code would reasonable.
I am curious about what sort of extensions you are adding? I think in
many cases writing functions that take in `Axes` (or `Figure` if that is
the right scope) objects and operate on them.
An example of a project that is sub-classing `Axes` is
GitHub - scls19fr/windrose: A Python Matplotlib, Numpy library to manage wind data, draw windrose (also known as a polar rose plot), draw probability density function and fit Weibull distribution .
Tom
On Sun, Jun 5, 2016 at 5:16 PM Daniel McNeela <daniel.mcneela at gmail.com> >> wrote:
Hi All,
I'm currently developing a Python package built on top of Matplotlib, and
I'd like to add custom functionality to the Axes class while still
retaining all of the default Matplotlib syntax and commands. To do this,
I'd like to subclass matplotlib.axes.Axes (or possibly
matplotlib.axes._base._AxesBase) and add additional class attributes and
methods. Ideally, I'd like to do this without forking Matplotlib and
directly editing the source so as to maintain compatibility with future
Matplotlib releases. I see that in pyplot.py, calls to figure() accept an
optional FigureClass argument which I could use to pass a custom subclass
of Figure. I was thinking I could subclass Figure such that the subclass
overrides methods such as Figure.add_subplot() by calling the superclass's
method and passing my custom Axes subclass in as an optional argument. But
I'm not sure which methods I'd have to override, or how deep the rabbit
hole goes, as Axes objects seem to be generated in a number of places
throughout the Matplotlib source.
If anyone who is familiar with the code base might be able to suggest a
simple way in which I could accomplish this desired behavior, I would
greatly appreciate it! Right now, I'm adding the desired functionality via
a function that accepts Matplotlib Axes instances and binds custom
attributes/methods to these instances via Python's type.MethodType, but
this seems like a rather clunky and un-Pythonic approach to building what
will likely be an extensive application.
Thank you in advance for your help!
Best,
Daniel McNeela
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
Matplotlib-devel Info Page