On 7/6/07, Paul Kienzle <[EMAIL PROTECTED]> wrote: > Hi, > > I've been playing with the pick infrastructure in 0.90 and find that > it doesn't meet my needs. The issue is that events from all artists > go to the same callback, so you are forced write your callback as a > series of if statements for each artist which may receive a pick event.
I definitely agree that having to write one callback for all the different objects you may want to pick on is a bad design, so I'd be happy to see something better. Do you think it would make sense to register callbacks with a given artist -- eg if you are picked call me -- or with a class (eg all Line3D picks call me), or do you have another approach in mind? > I would rather have an infrastructure more like a canvas, where I > can register callbacks to particular handles for particular > mouse events (enter, leave, motion, press and release). I would like > to rely on the zorder attribute of artists when processing the > events. If the callback succeeds, then the event is consumed and > no more handles are checked. If the callback fails then the next > lower zorder handle is checked. > > I can simulate what I want with the current infrastructure by having > the mouse events call figure.pick() and the pick event capture > every object that was picked, but it is ugly and not very > efficient (not every object wants to track enter/motion/leave > events for example, but they get asked on every pick even if > they only want to monitor mouse clicks). > > Instead I would like to start by splitting the current pick method > into two parts: > contains(event,picker) which returns truth value,details > pick(event) which generates the current pick event > > Later I can construct the infrastructure I want on the contains() > function for each artist. > > Does this approach seem reasonable to those who will approve the > patches I will send? I don't really understand the contains part -- can you elaborate a little bit? I would definitely be amenable to accepting patches that improve the current API :-) If you want to support things like mouse over, in which the pick will have to be computed on mouse motion, we'll want to do some caching, eg in line, to make this more efficient. The current approach is fairly expensive but that's fine for single click picks, but not for continuous mouse motion. JDH ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Matplotlib-devel mailing list Matplotlib-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
