RE : Toolbar2 stuff

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 :wink:

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

    >> 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

    > I called it Pan/Zoom (how original :wink: ). 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 :wink: )
    > 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.