|
From: Gregory L. <gre...@ff...> - 2004-07-26 13:04:09
|
Hi John, I have modified the fltk backend for toolbar2 and I am now quite happy with it's capabilities: *Zoomtorect and pan/zoom are toggle buttons, that can be activated/pushed or deactivated/raised Push on zoomtorect de-activate pan/zoom and vice-versa, and when none are activated one go back to initial situation (just the default pointer, no action (ideal would be to cache the callback associated to motion, push and release, so that one can go back to user-defined behavior) *rubber band is drawed during zoom_to_rect *motion_notify event is captured, i.e. pointer shape change when it enter axes if Pan/zoom or zoom_to_rect is active *pan/zoom is interractive, i.e. view is refreshed continuously when user drag the mouse keeping the button pushed (speed is ok, same as window resize) *zoom out to rect is implemented, works ok but is not as intuitive as I hoped (interrective pan/zoom is so good that it will be seldom used, I guess ;-) ). After testing it, I guess an interractive Pan/Zoom with shift_key pressed->zoomx=zoomy would be a worthier extension However, doing these modif I had some small problems: -it seems current CVS print ticker locator instances at redraw, I think since you corrected some ticker locator bug or something...very minor I guess -my first implementation of interractive pan/zoom was by defining a drag event: fltk is able to distinguish between a motion notify event (mouse move, no button pressed) and a button_drag event (mouse move with a button(s) pressed). This allows very clean and simple implementation, but when I tried to extend it to GTKAgg I was in trouble: it seems there is not 2 events generated, but that motion_notify have just the number of the button pressed (or None)... I emulated this in FltkAgg, collapsing the 2 events in one, and hacked an interractive pan/zoom over it but it is not as clean as the previous solution (change the mouse_move callback to pan_drag callback in pan_press, go back to mouse_move at pan_release)...A little extra benefit compensating for this is that the pointer stay a hand even if one go outside the window, and I autorized it for extra freedom in pan/zoom... Problem is that this do not allow me to port interrative Pan/Zoom to TkAgg or GTKAgg, which was the intended goal...I do not know why, as the axes instance a printed continuously during the drag, showing that figure is redrawed...but it shows to the screen only when I release the button :-( So I have 2 questions: -What do you think is the best event model: Separate events for DRAG/MOTION, or same one and use button info for differenting the 2? The second one (=current implementation) is simpler and cleaner in the sense that we have less events, but on the other hand in practive I guess one will often want to redefine the drag without changing motion, and in this case the 2 event is cleaner...Well, of course if there is no simple way to generate 2 event except in fltk, better to stay with 1 event for portability... -Why is the screen updated only after button release? Is there an extra operation to do except the draw, is screen updating blocked during events (maybe a double buffering?) ...Or I am doing something forbidden re-assigning callbacks within another callback? Best regards, Greg. PS: still no news from pyfltk guy nor any activity on the pyfltk list :( |