Re: RE : [matplotlib-devel] Toolbar2 stuff

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