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 > > On Fri, Aug 17, 2012 at 2:42 PM, Daniel Hyams <dhy...@gmail.com > <mailto:dhy...@gmail.com>> wrote: > > > > On Fri, Aug 17, 2012 at 2:25 PM, Michael Droettboom <md...@stsci.edu > <mailto:md...@stsci.edu>> 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 > dhy...@gmail.com <mailto:dhy...@gmail.com> > > > ------------------------------------------------------------------------------ > 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 > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > ------------------------------------------------------------------------------ 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 https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
