>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes: Gregory> Done...I used the relief method, it is probably more Gregory> portable across guis and use less screen estate. But Gregory> idealy a second push to the button should de-activate the Gregory> respective action (i.e. toggle mode), is this done in the Gregory> current CVS? Well, best way to know is to checkout ;-) This should be handled exclusively on your end, eg by binding 'pan/zoom' button press to a wrapper function which does the gui settings and then calls NavigationToolbar2.pan. >> I updated the way the pointer setting calls in CVS. Now you >> only get the special pointers when you are over an axes - >> otherwise you get the arrow pointer. I did this by connecting >> to the motion_notify_event. Gregory> Oups! This is good, but it make me realise I did not Gregory> understand the motion_notify_event, it mistake it for Gregory> drag event... Well, both are interresting, how about Gregory> adding some events? For now I have: button_press_event Gregory> button_release_event key_press_event key_release_event Gregory> *button_drag_event *button_double_press_event and I need Gregory> to add motion_notify_event Not sure we need draw since we effectively implement everything with press/ move/ mouse. The others would be good. The Event class / interface for key press events needs to be determined. It would be nice to support modifier keys. Feel free to take a stab at implementing this in backend_bases. double_click would also be worthwhile. >> I would like to have this on all the backends ideally. I could >> make a call from the NavigationToolbar2 - >> set_zoom_overlay(xmin, xmax, ymin, ymax) from the motion event. >> Would this help you? Todd , Steve, do you know how to do this >> in your respective backends? Theoretically, it could be done >> using matplotlib lines, but then the canvas would have to be >> redrawn and reblitted dynamically and I don't think the >> performance is good enough for that in most cases, especially >> for Tk which is slow for this kind of thing. Is there a native >> GUI solution for this on the respective backends? I added a few new (optional) methods to support the zoom to rectangle bounding box, aka rubber band. I implemented this in wx and gtk using native drawing so they are fast enough. The new methods are * draw_rubberband (optional) : draw the zoom to rect "rubberband" rectangle * press : (optional) whenever a mouse button is pressed, you'll be notified with the event * release : (optional) whenever a mouse button is released, you'll be notified with the event Gregory> Hum, the overlay problem is already solved for fltk Gregory> (although it is not so clean for the moment, it is done Gregory> between the fltk event interception and the event Gregory> conversion in MplEvent...)It use native fltk blitting, so Gregory> no redraw is involved, so you can consider it fully Gregory> solved on fltk... You may want to consider fitting this into the above framework, if possible. Gregory> I called it Pan/Zoom (how original ;-) ). Reagrding my Gregory> reverse zoom, in fact it have the same relationship with Gregory> right click for zoom out, than zoom to rectangle has to Gregory> the right click for zoom in: the 2 are similar and can Gregory> perform the same operation, but in a different manner Gregory> (right click with pan/zoom center operation on clicked Gregory> point, then interractively (well, in the future ;-) ) Gregory> zoom in/out, while zoom_to_rect is not interractive, the Gregory> user select the new zone that will be expaned to window Gregory> (zoom in as it is) or that the window will occupy (new Gregory> zoom out to rectangle)...Both can be used depending on Gregory> the situation and the user preference... Looks a little like unnecessary complexity (still don't really understand it) to me, but if you want to implement prototype, eg for fltk, I'll be happy to take it for a test drive later. Thanks, JDH