[matplotlib-devel] Toolbar2 stuff

Hello John, Hello Todd,

Toolbar2 is almost operational for FltkAgg... The "Almost" is because I
am currently testing it, but for now no bug has shown ;-) Still no news
from pyfltk guy, though, which will make testing by someone else more
difficult (I can always send my pyfltk, if someone is interrested...)

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

Appart from this, I have other (non-cosmetic ;-) )remarks:
*In TkAgg, right button Pan (i.e. zoom) does not seem to work, I think
that's for you Todd ;-)

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

*Having the motion_notify_event activated in toolbar 2 to activate
Pan/zoom interactively seems a good idea (i.e. continous pan/zoom, rcord
in the view stack on release). I can also draw a rectangle overlay when
doing a zoom_to_rect in fltkagg, this will make selection easier (but I
do not know if this is easy to do in other backends)...also, I'd like to
investigate my "reverse" zoom_to_rect idea, maybe using right click =
zoom out to rectangle/left click = zoom in to rectangle...this way with
2 buttons we have all navigation possibilities + a stack view, yay!!!
:-) 

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

*multiple axes
> > Open question is how to handle multiple axes.  I've considered:
> > 
> >   1) all or one checkbox
> > 
> >   2) just reuse old system (menu select) - but how do we deal with
> >      active in menu vs active via mouse.  I find the old way
> >      a bit cumbersome
> > 
> >   3) allow user to select multiple axes with the mouse - maybe make
> >      the selected axes have thicker borders to indicate selection.
> >      Hold down CTRL to select multiple active axes.
> 
> SHIFT?  (Don't know if it's even possible,  just thought 
> that's what is usually done for a multiple select.)
> 
> > 
> >   4) navigation only applies to axes under point (what we 
> have now in
> >      toolbar2)
> > 
> > I'm inclined to 1 or 4.  Users would have the option of toolbar : 
> > classic if they really need the multiple axes feature.  1 
> may be the 
> > best compromise.
> 
> For this afternoon,  I'm going for 4.  :-)  

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

Regarding the buffer optimisation, I have reimplemented it using double
inheritance and key test in FigureCanvasAgg draw method. it removes the
possible "buffer sharing" bug I mentioned before, so it is up-to-you,
john, to see if this is a better ay to do it: I did not test the
possible performance impact on GTKAgg (I can not see how it can be
nefast, but who knows?), but I have seen a lot of multiple inheritance
in backends so this is not a reason not to do it ;-)

Best regards,

Greg.