>>>>> "Todd" == Todd Miller <jm...@st...> writes: Todd> Hi John, Todd> Just... gasping... my... way... across... the... finish... line... now. Todd> Toolbar2 is operational for TkAgg and I really like it. Good to hear. 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. 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. Todd> I changed backend bases a little but don't think it breaks Todd> anything. I deleted the "button" parameter from a number of Todd> Toolbar2 methods, but since "button" wasn't used and was Todd> followed by *args, I don't think it hurts. Agreed. Vestigial from gtk. Todd> Is now a good time to commit? Do you want to see a tarball Todd> first? Fire when ready. The world waits with bated breath.... JDH
On Thu, 2004年07月22日 at 12:50, John Hunter wrote: > >>>>> "Todd" == Todd Miller <jm...@st...> writes: > > Todd> Hi John, > Todd> Just... gasping... my... way... across... the... finish... line... now. > > Todd> Toolbar2 is operational for TkAgg and I really like it. > > Good to hear. > > 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. :-) > > Todd> I changed backend bases a little but don't think it breaks > Todd> anything. I deleted the "button" parameter from a number of > Todd> Toolbar2 methods, but since "button" wasn't used and was > Todd> followed by *args, I don't think it hurts. > > Agreed. Vestigial from gtk. > > Todd> Is now a good time to commit? Do you want to see a tarball > Todd> first? > > Fire when ready. The world waits with bated breath.... The world can stop waiting... it's here!
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.
>>>>> "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
> 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 :-)
>>>>> "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
On Fri, 2004年07月23日 at 07:12, Gregory Lielens wrote: > Hello John, Hello Todd, > <SNIP> > 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 ;-) Got it. It's checked in. Thanks. Todd