matplotlib-devel Mailing List for matplotlib

I've added some of the features discussed on this list to the
navigation framework:

  * events now have a key attribute: an ascii char | 'control' |
    'shift' | 'alt'.  I yet haven't exposed key_press_event to
    mpl_connect though this isn't much more work.  I did this
    primarily so I could find out if 'x', 'y' or 'control' were
    pressed during pan/zoom right click events.  As discussed before,
    these three modifiers constrain the interactive zoom to x only, y
    only or proportion constrained.  I also am not currently handling
    key presses with modifiers but this is only a but more work - this
    can wait until key press is exposed through the mpl_connect
    interface.

 * dynamic update - an optional method dynamic_update refreshes the
   canvas during the navigation mouse move event.  

 * rubber banding - a visual rectangle using native drawing for zoom
   to rect.  Optional method is draw_rubberband.

All of the above are implemented in wx* and gtk* in CVS.

The major outstanding issue re navigation is multiple axes selection.
Still ruminating....  

I'd like to get all this wrapped up by next week if possible for 0.61.
There are some fairly important bugs in the last release (notably the
wxagg segfault on window resize) as well as nifty new features since
then (toolbar2, svg fixes, ps mathtext!!) that should be roaming free
in the while rather than caged up in CVS.

JDH

>>>>> "Stefan" == Stefan Kuzminski <pon...@ya...> writes:

    Stefan> Hi, I upgraded to libpng v1.2.5 from v1.0.14.  ( on a
    Stefan> linux box, using Agg backend and matplotlib v0.54.2 ) Now
    Stefan> I get this Runtime error thrown at _backend_agg.cpp line
    Stefan> 948

    Stefan> png_ptr = png_create_write_struct(PNG_LIBPNG_VER_STRING,
    Stefan> NULL, NULL, NULL); if (png_ptr == NULL) { fclose(fp);
    Stefan> throw Py::RuntimeError("could not create write struct");
    Stefan>   }

    Stefan> Has anyone seen this?

I just tried a built both matplotlib 0.54.2 and CVS against
libpng1.2.5 and was able to save an agg png w/o incident.  Make sure
you are not getting old png headers, have a clean matplotlib build,
run ldconfig, etc...

JDH

Hi,

I upgraded to libpng v1.2.5 from v1.0.14.  ( on a linux box, using Agg
backend and matplotlib v0.54.2 )  Now I get this Runtime error thrown
at _backend_agg.cpp line 948

png_ptr = png_create_write_struct(PNG_LIBPNG_VER_STRING, NULL, NULL,
NULL);
  if (png_ptr == NULL) {
    fclose(fp);
    throw Py::RuntimeError("could not create write struct");
  }

Has anyone seen this?

thanks,
Stefan


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 

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

    Steve> I viewed matplotlib.svg in gqview (on Linux) and it looks
    Steve> like the icon image only uses about two thirds of the svg
    Steve> width and height, so the minimize icon ends up being too
    Steve> small.

Indeed.  I fixed this in CVS (and a number of other fixes for SVG
including some layout problems, image support and font support).

There appears to be a problem with the svg lib gnome uses.  For one
thing, the axes appear black even though the hex code is #ffffff.
This does not happen in mozilla with the adobe plugin or with batik.
It appears GNOME uses the same lib (unsurprisingly) because when I
minimize the figure I also get the black axes background.

JDH

On Tue, 2004-07-27 at 04:36, John Hunter wrote:
> 
> 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
I viewed matplotlib.svg in gqview (on Linux) and it looks like the icon
image only uses about two thirds of the svg width and height, so the
minimize icon ends up being too small.

Steve

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

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

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

Regards,
Steve

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

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

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

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

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. 

John,

I don't know about your experience with debian, but 'stable' doesn't 
come with the version needed.

If I build freetype from scratch, pygtk would need to be rebuilt as well 
as Gtk etc. etc.
I have done this and it isn't a solution. That leaves me with TkAgg, 
which I don't want.
Wx is not really a solution either, as it is slow and heavy - I have to 
cater for P3-450Mhz style systems

debian is supposed to solve these issues, but
Unfortunately, I can't see a solution to this problem, other than to 
wait for testing to be declared stable in three months after three 
months after three months...

Cheers,
Malte.


John Hunter wrote:

>
>There's no need to upgrade the operating system, but you will need to
>upgrade freetype.  I recommend freetype 2.1.9 - 2.1.7 is required by
>matplotlib, but 2.1.9 fixes some bugs.
>
>With debian, a simple
>
>  > sudo apt-get install freetype freetype-dev 
>
>should do the trick.
>
>
>If your sysadmins won't do this for you, you can always compile a
>version in your home dir.
>  
>

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!

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

>>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:

    Malte> Hi , I can't build matplotlib-0.60.2 under woody.

    Malte> woody doesn't come with th latest freetype-dev It has
    Malte> version '2.0.9'

    Malte> ps And don't tell me not to use woody - our sys admins like
    Malte> to have a retro feeling.

There's no need to upgrade the operating system, but you will need to
upgrade freetype.  I recommend freetype 2.1.9 - 2.1.7 is required by
matplotlib, but 2.1.9 fixes some bugs.

With debian, a simple

  > sudo apt-get install freetype freetype-dev 

should do the trick.


If your sysadmins won't do this for you, you can always compile a
version in your home dir.

Have you tried installing matplotlib via debian:
http://matplotlib.sourceforge.net/installing.html#Debian?  There was a
recent thread on matplotlib-users regarding the debian apt install -
http://sourceforge.net/mailarchive/message.php?msg_id=8961454.

JDH

Last night hayden (jo...@on...) sent me a patch in which he
identified and fixed two leaks in _backend_agg.cpp, one in the
write_png method and one elsewhere.  Spurred on by his successes, I
tracked down and fixed some additional leaks in the _transforms and
ft2font modules.

Using units/memleak_hawaii3.py in CVS for test script, on typical runs
creating hundreds of random, complex figures, I get anywhere from -5
up to 40 bytes per figure.  Since this range is sometimes negative, it
may reflect statistical fluctuation.  This number is down from 400
bytes per figure in 0.60.2 (and 24K in 0.54.2) and is getting into the
"manageably small" range.  Of course, there is always the possibility
of a leak in an untested area, but I'm encouraged....

Lessons for developers (and me):

  * in pycxx extension code, you almost always want to return
    Py::asObject rather than Py::Object.  One exception is returning
    None as Py::Object().  This caused several leaks in the ft2font
    module.

  * Never incref where you meant to decref!  This was the cause of the
    leak in the _transforms module, which had escaped my earlier unit
    tests because I wasn't unit testing the leak of binary operations
    of lazy values.  In the BinOp class, I was incref-ing in the
    destructor.  Very bad...

  * Use freetype 2.1.9 since this fixes some leaks in earlier
    versions.

JDH

    Hello all,

    First I want to apologize for sending this message to both lists, 
but I couldn't decide which one is more appropriate and I would like to 
have an answer as soon as possible. I discovered matplotlib some while 
ago, but it wasn't until recently when I decided to integrate it into 
one of my programs, trying to replace PyPlot that doesn't have enough 
features for me. I downloaded and installed version 0.60.2. Your library 
seemed perfect, until I discovered some strange problems that prevented 
me from using it as this point :( Specifically, I'm reffering to the 
embedding_in_wx2.py example that I found in the 'examples' directory. I 
modified it as follows (sorry for inlining, but I don't know if the 
listserver accepts any attachements at all, I didn't use it before):

=================================================================

#!/usr/bin/env python
"""
An example of how to use wx or wxagg in an application w. or w/o the toolbar
"""

from matplotlib.numerix import arange, sin, pi

import matplotlib

# uncomment the following to use wx rather than wxagg
#matplotlib.use('WX')
#from matplotlib.backends.backend_wx import FigureCanvasWx as FigureCanvas

# comment out the following to use wx rather than wxagg
matplotlib.use('WXAgg')
from matplotlib.backends.backend_wxagg import FigureCanvasWxAgg as 
FigureCanvas

from matplotlib.figure import Figure

from wxPython.wx import *

class Cursor:
    def __init__(self, canvas, ax):
        self.canvas = canvas
        self.ax = ax


    def mouse_move(self, widget, event):
        height = self.ax.figure.bbox.height()
        x, y = event.x, height-event.y

        if self.ax.in_axes(x, y):
            # transData transforms data coords to display coords.  Use
            # the inverse method to transform back to data coords then
            # update the line

            # the cursor position
            x, y =  self.ax.transData.inverse_xy_tup( (x,y) )
            # the view limits
            minx, maxx = self.ax.viewLim.intervalx().get_bounds()
            miny, maxy = self.ax.viewLim.intervaly().get_bounds()

            print 'x=%1.2f, y=%1.2f'%(x,y)


class CanvasFrame(wxFrame):

    def __init__(self):
        wxFrame.__init__(self,None,-1,
                         'CanvasFrame',size=( 900,900 ) )

        self.SetBackgroundColour(wxNamedColor("WHITE"))

        self.figure = Figure( )
        self.axes = self.figure.add_subplot(111)
        t = arange(0.0,3.0,0.01)
        s = sin(2*pi*t)
        c = sin(4*pi*t)

        p = self.axes.fill(t,s,'b',t,c,'g')
        p[ 0 ].set_alpha( 0.2 )
        p[ 1 ].set_alpha( 0.2 )
        #p = self.axes.fill(t,s,'b')
        #p[ 0 ].set_alpha( 0.2 )
        #p[ 1 ].set_alpha( 0.2 )
        #self.axes.plot(t,c,'g')
        self.axes.vlines( [1.5], -1.0, 1.0 )

        self.canvas = FigureCanvas(self, -1, self.figure)

        self.sizer = wxBoxSizer(wxVERTICAL)
        self.sizer.Add(self.canvas, 1, wxTOP | wxLEFT | wxEXPAND)
        self.SetSizer(self.sizer)
        self.SetAutoLayout( True )
#        self.Fit()
        self.sizer.Fit( self )

        cursor = Cursor(self.canvas, self.axes)
        #cursor = SnaptoCursor(canvas, ax, t, s)
        self.canvas.connect('motion_notify_event', cursor.mouse_move)

        #self.add_toolbar()  # comment this out for no toolbar

        # Capture the paint message
        EVT_PAINT(self, self.OnPaint)
        EVT_SIZE( self, self.OnSize)

    def add_toolbar(self):
        self.toolbar = NavigationToolbar(self.canvas, True)
        self.toolbar.Realize()
        if wxPlatform == '__WXMAC__':
            # Mac platform (OSX 10.3, MacPython) does not seem to cope with
            # having a toolbar in a sizer. This work-around gets the buttons
            # back, but at the expense of having the toolbar at the top
            self.SetToolBar(self.toolbar)
        else:
            # On Windows platform, default window size is incorrect, so set
            # toolbar width to figure width.
            tw, th = self.toolbar.GetSizeTuple()
            fw, fh = self.canvas.GetSizeTuple()
            # By adding toolbar in sizer, we are able to put it at the 
bottom
            # of the frame - so appearance is closer to GTK version.
            # As noted above, doesn't work for Mac.
            self.toolbar.SetSize(wxSize(fw, th))
            self.sizer.Add(self.toolbar, 0, wxLEFT | wxEXPAND)
        # update the axes menu on the toolbar
        self.toolbar.update()


    def OnPaint(self, event):
#        self.canvas.draw()
        print "OnPaint"
#        if type( event ) == type( wxEvent ):
        event.Skip()

    def OnSize( self, event ):
        print "OnSize"
        print event.GetSize()
        event.Skip()
#        event.Skip()


class App(wxApp):

    def OnInit(self):
        'Create the main window and insert the custom frame'
        frame = CanvasFrame()
        frame.Show(true)

        return true

app = App(0)
app.MainLoop()

=================================================================

    The example shows just fine at first, but when I try to resize the 
windows it crashes (note that the original example also crashed under 
the same conditions). By "crashes" I mean that it exits with an 
unhandled exception, and Windows shows that the error is in 
_backend_agg.pyd. It also crashes if I change the initial figure size in 
.matplotlibrc (when changing figure.figsize from 8, 6 to 10, 10). I 
tried running in with Python 2.3.2 and Python 2.3.4, with wxPython 
2.4.2.4 and wxPython 2.5.1.5, but the result was the same. I inserted 
some debug statements in backend_wxagg.py and it seems that the crash is 
in 's = agg.tostring_rgb()', the program doesn't reach the line after 
this call. I modified the above code in a number of ways (including 
changing the code for OnPaint and OnSize as the documentation is not 
clear at all about their role and I don't know what I should do in these 
handlers), but I was unable to solve the problem.
    Note that the same example works fine with the simple WX backend, 
but this is no option for me, as I would really need alpha blending, and 
antialiasing wouldn't hurt too.
    Also, I need help with the initial plot size. When I create the plot 
it has very large margins to the parent frame. This is not convenient to 
me, as I'd like to have a plot that is as large as possible and margins 
as small as possible. Is there a way to modify these margins?
    Thank you for your patience in reading this e-mail and please help 
me if you can. I'm not subscribed to either matplotlib-users or 
matplotlib-devel, so please send your replies with a copy to 
bogdanal@b.astral.ro, or at least let me know if I need to be subscribed 
to the list in order to receive your answers regarding this issue.
    Thank you very much for your help.

    Bogdan Marinescu

Hi ,

I can't build matplotlib-0.60.2 under woody.

woody doesn't come with th latest freetype-dev
It has version '2.0.9'

The following error occurs.

src/ft2font.cpp: In method `class Py::Object 
FT2Font::get_ps_font_info(const Py::Tuple &)':
src/ft2font.cpp:811: `PS_FontInfoRec' undeclared (first use this function)
src/ft2font.cpp:811: (Each undeclared identifier is reported only once
src/ft2font.cpp:811: for each function it appears in.)
src/ft2font.cpp:811: parse error before `;'
src/ft2font.cpp:813: `fontinfo' undeclared (first use this function)
src/ft2font.cpp:813: implicit declaration of function `int 
FT_Get_PS_Font_Info(...)'


PS_FontInfoRec is not present in the woody freetype.


ps And don't tell me not to use woody - our sys admins like to have a 
retro feeling.

Cheers,
Malte.

I upgraded agg in cvs to agg 2.1.   Probably best to flush your build
dir before rebuilding.  Let me know if you have any build troubles -
on my system it was totally seamless.

In other news, I've ported the new toolbar and event handling to
wx/wxagg. The new buttons are as follows:

  HOME    : reset all axes to initial view

  BACK    : reset axes to previous view limits in stack

  FORWARD : reset axes to next view limits in stack

  PAN     : with left button press/release pan and with right button
            press/release zoom.  For pan, the coord under point at
            press will be moved to coord under point at release.  For
            zoom, movements to the right will zoom in on x axes and
            movements to the left will zoom out.  Ditto for y and
            up/down.  Amount of zoom will be proportionate to distance
            mouse travels over x and y between press and release.
            Diagonal movements will zoom both accordingly.

  ZOOM_TO_RECT  : self explanatory

  SAVE  : as in classic

The toolbar choice is determined by the new rc param 'toolbar' which
can be None, classic or toolbar2.

Todd, you may want to take a look at porting this to TkAgg and Gregory
to FLTK.  My guess is you (Todd) can do this in half an hour or so
since it's basically a slight generalization of the connect scheme you
came up with.  It may take a bit longer for you Gregory if you haven't
implemented FigureCanvas.connect yet.

The new toolbar class, backend_bases.NavigationToolbar2, does 95% of
the work and basically just uses the backend to load up the GUI
widgets and make the event calls.  I've uploaded several new (slicker)
widget icons to CVS that you should use to make the toolbar -
described below

The derived toolbar must define

    def set_cursor(self, cursor):
        'Set the current cursor to one of the cursors values'
        OPTIONAL

where the cursors are ints defined in backend_bases as

  # cursors
  class Cursors:  #namespace
      HAND, POINTER, SELECT_REGION = range(3)
  cursors = Cursors()

and you can use them (optionally) to set the screen pointer icon
depending on the user tool (eg HAND vs SELECT_REGION).  See
backend_gtk for an example mapping the constants to GTK cursor
constants.
     
    def _init_toolbar(self):

This is where you actually build the GUI widgets (called by __init__).
The  icons home.xpm, back.xpm, forward.xpm, hand.xpm, zoom_to_rect.xpm
and filesave.xpm are standard across backends (there are ppm versions
in CVS also).

You just need to set the callbacks

  home         : self.home
  back         : self.back
  forward      : self.forward
  hand         : self.pan
  zoom_to_rect : self.zoom
  filesave     : self.save_figure

You only need to define the last one - the others are in the base
class implementation.

    def save_figure(self, button):

identical to other toolbar

See backend_bases.FigureCanvasBase.mpl_connect,
backend_bases.FigureCanvasBase.mpl_disconnect and
backend_bases.MplEvent for information on the (slightly modified)
connection methods.  FigureCanvasBase.connect is deprecated and should
warn or do what you think appropriate.

The callback signature is now

  func(event)

rather than 

  func(widget, event)

since the former was GTK specific and I didn't see the logic of
including widgets in GUI neutral callbacks.  Also, the event contains
more information - x and y in display (flipped if nec.) coords, the
axes the pointer is over (if any) and the x and y in data coords if
the pointer is over an axes.  Both wx and gtk implement the connection
wrapper so it should be easy to follow them.

The examples/coords_demo.py is modified to work with the new code.

Some things are not finished yet - right now the navigation only
applies to the axes under point.  I'm still thinking about how this
should be handled.  

JDH

>>>>> "Paul" == Paul Barrett <ba...@st...> writes:

    Paul> False alarm.  It now works - after blowing away the build
    Paul> tree and rebuilding the entire package.

I've seen the same thing - don't know the cause.

JDH