matplotlib-devel Mailing List for matplotlib

>>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:

    Steve> I've added an icon for use for when matplotlib windows are
    Steve> minimized and chose an arbitrary icon (back.svg) to get it
    Steve> working on the GTK+ backend. Since the icon has to be
    Steve> resized to fit in the panel, and svg are good at resizing,
    Steve> I used svg instead of the usual png format (png or other
    Steve> formats could be used instead if required).

    Steve> John, if you can find/create a suitable matplotlib icon
    Steve> just copy it to images/matplotlib.svg and overwrite the
    Steve> existing icon file.

I had the bright idea to use the svg backend to generate the
minimization icon.  See examples/matplotlib_icon.svg.  It displays
correctly on my web browser, but not when minimized.  I don't know if
this reflects a problem in the svg backend, or how gtk handles svg
icons.

If we can get this example to work, the next thing to do is connect
the icon setting to the window minimize event, and set the icon to be
the svg output of the current figure window!

JDH

> -----Message d'origine-----
> De : mat...@li...=20
> [mailto:mat...@li...] De la=20
> part de John Hunter
> Envoy=E9 : lundi 26 juillet 2004 21:26
> =C0 : mat...@li...
> Objet : [matplotlib-devel] constrained zoom
>=20
>=20
>=20
> One more thought on interactive zoom.  As I was trying out=20
> the interactive zoom (not zoom to rect, but right click on=20
> pan zoom) on some image data, I noticed that it would be=20
> useful to have some constraints on the zoom
>=20
>   - zoom only on x.  Already the x zoom is determined by the amount of
>     movement in the horizontal direction, but it would be nice to be
>     able to ignore the y direction.  Candidate key modifier: 'x'
>=20
>   - zoom only on y.  ditto. Candidate key modifier: 'y'
>=20
>   - preserve axes aspect ratio.  Candidate key modifier: ??.  I think
>     some apps use a SHIFT or a CTRL modifier for this.  Is there any
>     consensus or common practice?

Yes, this will be very usefull! Add the group of axis (all of them react
to pan/zoom/zoom_to_rect of any of them, and it would be the ultimate
plot navigation tool :-) I go for shift for the last one (could even do
the 3 in one, kind of like power point snap to grid, except grid would
be 0/45/90 direction. I think powerpoint and many drawing program (adobe
illustrator, corel draw) act like that :-)

One more thought on interactive zoom.  As I was trying out the
interactive zoom (not zoom to rect, but right click on pan zoom) on
some image data, I noticed that it would be useful to have some
constraints on the zoom

  - zoom only on x.  Already the x zoom is determined by the amount of
    movement in the horizontal direction, but it would be nice to be
    able to ignore the y direction.  Candidate key modifier: 'x'

  - zoom only on y.  ditto. Candidate key modifier: 'y'

  - preserve axes aspect ratio.  Candidate key modifier: ??.  I think
    some apps use a SHIFT or a CTRL modifier for this.  Is there any
    consensus or common practice?

JDH

>>>>> "Gregory" == Gregory Lielens <gre...@ff...> writes:
    Gregory> *zoom out to rect is implemented, works ok but is not as
    Gregory> intuitive as I hoped (interrective pan/zoom is so good
    Gregory> that it will be seldom used, I guess ;-) ).  After
    Gregory> testing it, I guess an interractive Pan/Zoom with
    Gregory> shift_key
    pressed-> zoomx=zoomy would be a worthier extension

I say we drop it then.  Obviously you are free to do what you want on
your backend, but it doesn't sound like it adds enough to incorporate
it into the general framework.

    Gregory> However, doing these modif I had some small problems:

    Gregory>  -it seems current CVS print ticker locator instances at
    Gregory> redraw, I think since you corrected some ticker locator
    Gregory> bug or something...very minor I guess 

Fixed, thanks

    Gregory> the intended goal...I do not know why, as the axes
    Gregory> instance a printed continuously during the drag, showing
    Gregory> that figure is redrawed...but it shows to the screen only
    Gregory> when I release the button :-(

...snip 

    Gregory> -Why is the screen updated only after button release? Is
    Gregory> there an extra operation to do except the draw, is screen
    Gregory> updating blocked during events (maybe a double
    Gregory> buffering?) ...Or I am doing something forbidden
    Gregory> re-assigning callbacks within another callback?

The reason was performance.  tk blits slowly do it is hard to get
interactive refresh rates.  Also, matplotlib can be slow for some
figures, so I didn't want to bod down performance with interactive
redraws.  

In retrospect, I think it is a good idea to support dynamic updates.
I recoded the navigation toolbar base class a bit to call a method
dynamic_update during pan/zoom mode and implemented this for gtk (not
yet wx).  It is a *very nice* feature, IMO.  I had to trap the button
press and release events in gtk because button wasn't defined on a
drag (I guess this is the purpose of a drag event :-).  My preference
for now is to not add a separate drag event to mpl_connect for
simplicity, but I'm open to it if you and the rest of the gang think
we should.  We can always add it later.

Todd, you may want to take a stab at implementing this in tkagg --
you'll like it!  For the slower interactive backends (wx*, tk) it may
be a good idea to make the dynamic update an rc param.

JDH

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