Done...I used the relief method, it is probably more
> portable across guis and use less screen estate. But
> idealy a second push to the button should de-activate the
> respective action (i.e. toggle mode), is this done in the
> 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.
> Oups! This is good, but it make me realise I did not
> understand the motion_notify_event, it mistake it for
> drag event... Well, both are interresting, how about
> adding some events? For now I have: button_press_event
> button_release_event key_press_event key_release_event
> *button_drag_event *button_double_press_event and I need
> 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
> Hum, the overlay problem is already solved for fltk
> (although it is not so clean for the moment, it is done
> between the fltk event interception and the event
> conversion in MplEvent...)It use native fltk blitting, so
> no redraw is involved, so you can consider it fully
> solved on fltk...
You may want to consider fitting this into the above framework, if
possible.
> I called it Pan/Zoom (how original ). Reagrding my
> reverse zoom, in fact it have the same relationship with
> right click for zoom out, than zoom to rectangle has to
> the right click for zoom in: the 2 are similar and can
> perform the same operation, but in a different manner
> (right click with pan/zoom center operation on clicked
> point, then interractively (well, in the future )
> zoom in/out, while zoom_to_rect is not interractive, the
> user select the new zone that will be expaned to window
> (zoom in as it is) or that the window will occupy (new
> zoom out to rectangle)...Both can be used depending on
> 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