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 :(