I’m not sure where to say that I just posted up a new MEP, but here it is:
https://github.com/matplotlib/matplotlib/wiki/MEP9
and I suppose we discuss it here…
···
–
Daniel Hyams
dhyams@…149…
Thanks for this. The first "real" MEP!
My view is that we can discuss this here, and then you would be ultimately responsible for updating the MEP based on feedback -- but this is a new process, we can be as flexible as we want.
I've read it through once and think it's a very valuable idea in general. I'll send my comments once I've had time to further digest it.
Cheers,
Mike
···
On 08/15/2012 02:10 PM, Daniel Hyams wrote:
I'm not sure where to say that I just posted up a new MEP, but here it is:
MEP9 · matplotlib/matplotlib Wiki · GitHub
and I suppose we discuss it here...
--
Daniel Hyams
dhyams@...149... <mailto:dhyams@…149…>------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
OK - I’ll start the ball rolling…
One feature that would be nice to have is positioning options that are not pixel based. See the annotate function for some possibilities:
http://matplotlib.sourceforge.net/api/pyplot_api.html#matplotlib.pyplot.annotate
I’m not sure if all of these options are practical for a general artist but they do come in handy. Being able to position something as a percentage of the figure or an axes is a really nice feature when making nice looking plots. This is especially true
for text. We implemented something for dragging annotations around and saving the results (in a custom xml file) that kept the initial method the user used (%, data, pixel) with the updated location. We didn’t implement a resizing capability but that would
have been great to have for each axes object in the figure.
FYI the app we made used MPL and basemap to display the landing uncertainties and hazard probabilities for the Mars Curiosity rover on the Martian surface (very cool stuff). There was a lot of data and labels on the graphs and the navigation team needed
to quickly make presentation grade images that people could easily read. Being able to drag the annotations, legend, etc around was huge and since data was updated every day, being able to save the drag and drop locations and restore them from the xml file
with new data the next day made things a lot faster.
Ted
···
From: Daniel Hyams [dhyams@…149…]
Sent: Wednesday, August 15, 2012 11:10 AM
To: matplotlib-devel@lists.sourceforge.net
Subject: [matplotlib-devel] MEP9: interactivity
I’m not sure where to say that I just posted up a new MEP, but here it is:
https://github.com/matplotlib/matplotlib/wiki/MEP9
and I suppose we discuss it here…
–
Daniel Hyams
dhyams@…149…
Note that the get_pixel_position_ll() and such functions (in the MEP9 proposal) are only for internal use by the interactive manager. Items can still be placed by the script wherever necessary, and if the position (in one or multiple transformations) is necessary, one can record that in the on_select_end callback for that artist.
In fact, one of the things that must be done in the set_position_and_size() call (every artist will have to do this) is to set that artist’s appropriate parameters for its position and size, based on its current transformation, that fits it within the bounding box that the user just finished moving and dragging around. Sorry, I know that’s hard to see without some straw-man code that I intend to post soon…I was a little ashamed to post it in its current state 
···
On Fri, Aug 17, 2012 at 10:52 AM, Drain, Theodore R (343P) <theodore.r.drain@…179…> wrote:
OK - I’ll start the ball rolling…
One feature that would be nice to have is positioning options that are not pixel based. See the annotate function for some possibilities:
Here's my initial thoughts:
There are a few examples in the event_handling that are going to be much simplified by this new infrastructure. They should be updated to point people in the direction of this new/better/easier way.
How do the *select* methods relate to the existing pick functionality? Does it replace or complement? Are there any inconsistencies in usage between the two?
Other than that, I'm not seeing any obvious issues with the MEP. I'd love to see the code when it's ready.
Mike
···
On 08/15/2012 02:10 PM, Daniel Hyams wrote:
I'm not sure where to say that I just posted up a new MEP, but here it is:
MEP9 · matplotlib/matplotlib Wiki · GitHub
and I suppose we discuss it here...
--
Daniel Hyams
dhyams@...149... <mailto:dhyams@…149…>------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
Here’s my initial thoughts:
There are a few examples in the event_handling that are going tobe much simplified by this new infrastructure. They should be
updated to point people in the direction of this new/better/easier
way.How do the *select* methods relate to the existing pickfunctionality? Does it replace or complement? Are there any
inconsistencies in usage between the two?
I think that in most use cases that I can think of, a user would want to either use the picking mechanism, which fires an event, or go “whole hog” and use the interactive manager. Not both…if I remember correctly, I do call set_picker() in the interactive manager, so that I can set a reasonable tolerance around the artist for containment purposes…otherwise it’s too hard to point exactly at a line, for example. So there is some potential for interference there that would need to be looked after in the new code.
As an aside, all of the on_* methods really encourage the user to use matplotlib in object oriented way, which I really like, but probably most people won’t. As a bridge for the functional-style users of mpl, we could just implement all of the on_* methods in the artist.Artist class by default by having them fire an event. Then if someone overrides the method, fine, but if they don’t, there is an event fired.
Other than that, I'm not seeing any obvious issues with the MEP.I’d love to see the code when it’s ready.
I’ll probably have an example code, still in its mix-in form, in a branch for you to look at soon. This way, the discussion can turn more concrete. The example code will also be a runnable sample so that you can play with the interactivity.
···
On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom <mdroe@…31…> wrote:
I was planning to just create my own branch to start putting code in, but would it be better for an admin to create a branch off of master in the main matplotlib repo (say MEP9)? Then whoever wants to help out with MEP9 can branch from that and issue pull requests against it?
···
On Fri, Aug 17, 2012 at 2:42 PM, Daniel Hyams <dhyams@…149…> wrote:
On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom <mdroe@…31…> wrote:
Here’s my initial thoughts:
There are a few examples in the event_handling that are going tobe much simplified by this new infrastructure. They should be
updated to point people in the direction of this new/better/easier
way.How do the *select* methods relate to the existing pickfunctionality? Does it replace or complement? Are there any
inconsistencies in usage between the two?
I think that in most use cases that I can think of, a user would want to either use the picking mechanism, which fires an event, or go “whole hog” and use the interactive manager. Not both…if I remember correctly, I do call set_picker() in the interactive manager, so that I can set a reasonable tolerance around the artist for containment purposes…otherwise it’s too hard to point exactly at a line, for example. So there is some potential for interference there that would need to be looked after in the new code.
As an aside, all of the on_* methods really encourage the user to use matplotlib in object oriented way, which I really like, but probably most people won’t. As a bridge for the functional-style users of mpl, we could just implement all of the on_* methods in the artist.Artist class by default by having them fire an event. Then if someone overrides the method, fine, but if they don’t, there is an event fired.
Other than that, I'm not seeing any obvious issues with the MEP.I’d love to see the code when it’s ready.
I’ll probably have an example code, still in its mix-in form, in a branch for you to look at soon. This way, the discussion can turn more concrete. The example code will also be a runnable sample so that you can play with the interactivity.
–
Daniel Hyams
dhyams@…149…
I was planning to just create my own branch to start putting code in,
but would it be better for an admin to create a branch off of master in
the main matplotlib repo (say MEP9)? Then whoever wants to help out
with MEP9 can branch from that and issue pull requests against it?
People can already do that by forking your repo (which you forked from master), and issuing pull requests against your MEP9 branch within it. The difference is that in the latter case, you are the only one who can merge a pull request. I think this will have some advantages, including giving you more freedom to do things like rebase and force-push, which we would not want to do in the main repo.
Eric
···
On 2012/08/17 8:45 AM, Daniel Hyams wrote:
On Fri, Aug 17, 2012 at 2:42 PM, Daniel Hyams <dhyams@...149... > <mailto:dhyams@…149…>> wrote:
On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom <mdroe@...31... > <mailto:mdroe@…31…>> wrote:
Here's my initial thoughts:
There are a few examples in the event_handling that are going to
be much simplified by this new infrastructure. They should be
updated to point people in the direction of this
new/better/easier way.How do the *select* methods relate to the existing pick
functionality? Does it replace or complement? Are there any
inconsistencies in usage between the two?I think that in most use cases that I can think of, a user would
want to either use the picking mechanism, which fires an event, or
go "whole hog" and use the interactive manager. Not both....if I
remember correctly, I do call set_picker() in the interactive
manager, so that I can set a reasonable tolerance around the artist
for containment purposes...otherwise it's too hard to point exactly
at a line, for example. So there is some potential for interference
there that would need to be looked after in the new code.As an aside, all of the on_* methods really encourage the user to
use matplotlib in object oriented way, which I really like, but
probably most people won't. As a bridge for the functional-style
users of mpl, we could just implement all of the on_* methods in the
artist.Artist class by default by having them fire an event. Then
if someone overrides the method, fine, but if they don't, there is
an event fired.Other than that, I'm not seeing any obvious issues with the MEP.
I'd love to see the code when it's ready.I'll probably have an example code, still in its mix-in form, in a
branch for you to look at soon. This way, the discussion can turn
more concrete. The example code will also be a runnable sample so
that you can play with the interactivity.--
Daniel Hyams
dhyams@...149... <mailto:dhyams@…149…>------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options
OK, thanks Eric. I’ll try my best not to let my git-ignorance “git” in the way too much
···
On Fri, Aug 17, 2012 at 3:24 PM, Eric Firing <efiring@…229…> wrote:
On 2012/08/17 8:45 AM, Daniel Hyams wrote:
I was planning to just create my own branch to start putting code in,
but would it be better for an admin to create a branch off of master in
the main matplotlib repo (say MEP9)? Then whoever wants to help out
with MEP9 can branch from that and issue pull requests against it?
People can already do that by forking your repo (which you forked from
master), and issuing pull requests against your MEP9 branch within it.
The difference is that in the latter case, you are the only one who can
merge a pull request. I think this will have some advantages, including
giving you more freedom to do things like rebase and force-push, which
we would not want to do in the main repo.
Eric
OK, I have a sample code for people to run if they want to. I’ve dumped all of the interactive manager code and some sample usage (of the mix-in way of doing it) in the following branch:
https://github.com/dhyams/matplotlib/tree/MEP9
in the directory
examples/user_interfaces/imanager.py
Just run that script, and it should give a little demo plot. I do apologize and disclaim all messiness in the code…it’s not the prettiest thing anyway, and I cobbled it together very quickly so that you could see what it does. Sort of a straw man to beat on, I guess.
···
On Fri, Aug 17, 2012 at 3:38 PM, Daniel Hyams <dhyams@…149…> wrote:
On Fri, Aug 17, 2012 at 3:24 PM, Eric Firing <efiring@…229…> wrote:
On 2012/08/17 8:45 AM, Daniel Hyams wrote:
I was planning to just create my own branch to start putting code in,
but would it be better for an admin to create a branch off of master in
the main matplotlib repo (say MEP9)? Then whoever wants to help out
with MEP9 can branch from that and issue pull requests against it?
People can already do that by forking your repo (which you forked from
master), and issuing pull requests against your MEP9 branch within it.
The difference is that in the latter case, you are the only one who can
merge a pull request. I think this will have some advantages, including
giving you more freedom to do things like rebase and force-push, which
we would not want to do in the main repo.
Eric
OK, thanks Eric. I’ll try my best not to let my git-ignorance “git” in the way too much
–
Daniel Hyams
dhyams@…149…