Re: [matplotlib-devel] Toolbar2 stuff

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:

    Gregory> The new toolbar is great, and new button image too (is
    Gregory> the background transparent, or not? If not and if it is
    Gregory> possible, one minor cosmetic improvement would be to have
    Gregory> transparent background button, they show lighter than my
    Gregory> fltk buttons for now...Well, if it is not possible I
    Gregory> guess I have to overide fltk default to use same color as
    Gregory> the images background)

Can fltk use pngs?  I just uploaded some pngs with transparent
backgrounds to CVS (revision 1.2)

    Gregory> *As mentioned in by someone on the list previously, I
    Gregory> think having button that indicate the status (like toggle
    Gregory> button, or light button, or button that remains pushed)
    Gregory> for Pan/Zoom and Zoom would be great. This way, one can
    Gregory> return to arrow pointer and default (or user set
    Gregory> callback)...For now this seems not possible (or maybe I
    Gregory> did not find the way to do it?) In fltkagg I already put
    Gregory> some light buttons for those, but this behavior is not
    Gregory> activated in toolbar2 so there is not much point doing so
    Gregory> for the moment

Indicating the button status via relief or whatever is nice, and this
is something that can be done on a backend basis.  If you , Todd or
Steve have ideas on how best to do this for the respective backends,
go for it.

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> *Having the motion_notify_event activated in toolbar 2 to
    Gregory> activate Pan/zoom interactively seems a good idea
    Gregory> (i.e. continous pan/zoom, rcord in the view stack on
    Gregory> release). I can also draw a rectangle overlay when doing
    Gregory> a zoom_to_rect in fltkagg, this will make selection
    Gregory> easier (but I do not know if this is easy to do in other
    Gregory> backends)...also, 

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?

    Gregory> I'd like to investigate my "reverse"
    Gregory> zoom_to_rect idea, maybe using right click = zoom out to
    Gregory> rectangle/left click = zoom in to rectangle...this way
    Gregory> with 2 buttons we have all navigation possibilities + a
    Gregory> stack view, yay!!!  :-)

How is your "reverse zoom" idea different from the right click zoom
in/out with the hand/pan button (implemented in gtk and wx but not yet
in tk)?  With that button activated, right click drag motions to the
left and down zoom out. And what should we call that button anyway?
Pan is not a good name since it pans and zooms.

    Gregory> *Something that occur in both TkAgg, GTKAgg and FltkAgg
    Gregory> (so it is in toolbar2 base class, I guess) is a
    Gregory> non-conventional stack view behavior (I do not know if it
    Gregory> is intended or not, so I will not scream bug! bug!  too
    Gregory> fast ;-) ): When we navigate with pan/zoom or
    Gregory> zoom_to_rect, views are added in the stack, and one can
    Gregory> go back and further with the previous/next arrows.  But
    Gregory> if one go back to arbitrary position in the stack (with
    Gregory> back or home) and define a new view (pan/zoom again),
    Gregory> this does not replace all the view further in the stack,
    Gregory> but just add this view on top of the stack without
    Gregory> removing any view (hum, this is not so easy to explain
    Gregory> ;-) ).  This is ok in itself, but I find it non-intuitive
    Gregory> cause it does not correspond to a webbrowser or any
    Gregory> undo/redo or back/previous scheme I have encountered
    Gregory> before...So is this intentional?

No.  I fixed it.  When you get a new CVS checkout (there should be a
class Stack defined in backend_bases) make sure it works as expected.
Factoring the navigation stack into a dedicated class cleaned up the
NavigationToolbar2 base code considerably.

    Gregory> Me too :-) I'd like to go further though, I thing the
    Gregory> multiple axes in toolbar1 was a great idea (so do you
    Gregory> Tood, if you keep Axes menu in TkAgg toolbar 2 as a
    Gregory> reminder of the feature...That's what I have done too in
    Gregory> FltkAgg ;-) ) Something like a master/slave idea maybe?
    Gregory> Axes defined as slave of another axe would reproduce the
    Gregory> navigation done in the first one...or a bind notion: all
    Gregory> the axes in the bind group react to navigation within any
    Gregory> axe in the group...Well, these are possible stuff to do
    Gregory> with command line, but a good idea to expose these in the
    Gregory> toolbar remains to be found :-)

I've thought about the master/slave idea before.  There are a number
of examples when you want to bind one axes view lim to another.  This
could be done with an observer pattern, where axes notify observers
when a view lim is set.

In code, you could call

  ax1.add_xlim_observer(ax2)

But I don't know how this would best be handled in the GUI.  Also,
more often than not you would want changes in ax1 to affect ax2 and
vice versa.  Ie, not master-slave but bidirectionally coupled.

JDH