RE : [matplotlib-devel] Toolbar2 stuff

[Gregory L. <gre...@ff...>]

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

I will check that, for now I have already a "good enough"(TM) solution,
I shrinked my buttons so that image cover the whole button :-)

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

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

> 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

What do you think of these?

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


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


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

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

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

Great, I will checkout the CVS :-)

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

Yes, so linking some axes in a group where any new view lim is
broadcasted to all group members...problem would be to defines theses
groups in the gui (easy if one can define only 1 group, and the rest of
axes is independent: it is re-use of the current axes menu, what do you
think of that for a start? It should cover most of the use already :-)