matplotlib-devel Mailing List for matplotlib (Page 2)

John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
>     Charles> 	I think the slider should update with the display if
>     Charles> the dragging is enabled, so the slider value stays in
>     Charles> sync.  The typical user will understand that things will
>     Charles> be a little sliggish when plotting insane data such as
>     Charles> you example.  I am wanting to create a simple text/value
>     Charles> entry field, but I noticed that the backends don't
>     Charles> support the delete key in events.  Are there issues
>     Charles> across platforms with this?  If not, I will probably add
>     Charles> this.
> 
> Yes, you should add the delete key.  I was hacking a little bit
> yesterday on text entry.  An alternative to creating a text widget is
> to simply require each backend to define a few gui dependent functions
> that we don't to get involved with (get_filename, get_text, etc..) and
> then connect these to a button.  The button could say something like

Since I can't really offer much help on this topic (outside of my field 
of expertise), I'd be glad to assist with the PR effort for the upcoming 
MDE release.  I know you guys will be quite busy with the code, so I can 
work on writing the release announcements.  A first draft for your 
consideration:

------------------------
MDE: the Matplotlib Desktop Environment

John D. Hunter and the Matplotlib team proudly announce the dawn of a 
new era in interactive graphical desktops: MDE,  the Matplotlib Desktop 
Environment, is coming!  Are you tired of the endless Qt/GTK, 
KDE/Gnome/OSX debates?  Cry no more!  MDE is here, to provide a fully 
anti-aliased destkop environment with run-time backend selection (Tk, 
GTK, WX, Qt, FLTK and even CocoaAgg are supported, so there is room for 
all).

The first (alpha) release of MDE will include full scientific plotting 
capabilities, a testament to the vision of the core team.  Secondary 
utilities like file managers, web browsers and a python-based Office 
Suite (MatPlotOffice -- in development at the MPL underground 
laboratories), will come later...

So stop using KDE/Gnome now, and join the MDE fun!  You haven't really 
experienced modern computing until you've used MDE...
------------------------

I know it's a bit hyperbolic, but isn't that what a PR release is 
supposed to do?  Besides, we want the KDE and Gnome teams to take notice 
of the new kid on the block ASAP, so we better be loud from day one.

;-)

Cheers,

f

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> 	I think the slider should update with the display if
    Charles> the dragging is enabled, so the slider value stays in
    Charles> sync.  The typical user will understand that things will
    Charles> be a little sliggish when plotting insane data such as
    Charles> you example.  I am wanting to create a simple text/value
    Charles> entry field, but I noticed that the backends don't
    Charles> support the delete key in events.  Are there issues
    Charles> across platforms with this?  If not, I will probably add
    Charles> this.

Yes, you should add the delete key.  I was hacking a little bit
yesterday on text entry.  An alternative to creating a text widget is
to simply require each backend to define a few gui dependent functions
that we don't to get involved with (get_filename, get_text, etc..) and
then connect these to a button.  The button could say something like


 --------------------
|  xlabel: volts(s) |
 --------------------


and when you click on it calls get_text from the backend and updates
"volts(s)" with the text you supply (and in this example would update
the xlabel too).

Below is a buggy and incomplete example of using the region/cache/copy
stuff I mentioned before to type into an axes.  As before, it is
gtkagg only at this point.  In particular, the cursor is pretty
crappy.  Note I am using "None" which is what backspace currently
defines, to indicate the backspace key.  One thing that would make
this work better is to predefine the region the text goes into (an
Axes presumably) and just blit the entire axes bbox before
re-rendering the string with each character.  This would solve the
cursor erase on backspace bug you will notice if you try it.

This was just screwing around and not meant for public consumption,
but since you brought it up :-)

Anyone want to write a word processor in matplotlib <wink>?


## Example text entry ##

from pylab import *
from matplotlib.transforms import lbwh_to_bbox, identity_transform


class TextBox:
    def __init__(self, canvas, s='Type: '):
        self.canvas = canvas
        self.text = text(0.5, 0.5, s)
        draw()
        canvas.mpl_connect('key_press_event', self.keypress)        
        self.region = canvas.copy_from_bbox(self.get_padded_box())
        l,b,r,t = self.get_cursor_position()
        self.cursor, = plot([r,r], [b,t])

        
    def keypress(self, event):
        if event.key is not None and len(event.key)>1: return

        t = self.text.get_text()
        if event.key is None: # simulate backspace
            if len(t): newt = t[:-1]
            else: newt = ''
        else:            
            newt = t + event.key
            
        oldbox = self.get_padded_box()
        self.text.set_text(newt)
        newbox = self.get_padded_box()

        l,b,r,t = self.get_cursor_position()
        self.cursor.set_xdata([r,r])
        self.cursor.set_ydata([b,t])
        
        canvas = self.canvas
        canvas.restore_region(self.region)
        self.region = canvas.copy_from_bbox(newbox)
        f.draw_artist(self.text)
        f.draw_artist(self.cursor)                    
        canvas.blit(oldbox)
        canvas.blit(newbox)
        
    def get_padded_box(self, pad=5):
        l,b,w,h = self.text.get_window_extent().get_bounds()
        return lbwh_to_bbox(l-pad, b-pad, w+2*pad, h+2*pad)


    def get_cursor_position(self):
        l,b,w,h = self.text.get_window_extent().get_bounds()
        r = l+w+5
        t = b+h
        l,b = self.text.get_transform().inverse_xy_tup((l,b))
        r,t = self.text.get_transform().inverse_xy_tup((r,t))
        return l,b,r,t
        

        
ion()
f = figure()
title('Start typing')
axis([0, 2, 0, 1])    
box = TextBox(f.canvas)
axis([0, 2, 0, 1])    

show()

	I think the slider should update with the display if the dragging is
enabled, so the slider value stays in sync.  The typical user will
understand that things will be a little sliggish when plotting insane
data such as you example.
	I am wanting to create a simple text/value entry field, but I noticed
that the backends don't support the delete key in events.  Are there
issues across platforms with this?  If not, I will probably add this.

- Charlie

John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
>     Charles> 	draw_idle still seems to suffer from the "trying to
>     Charles> catch up" problem.  I added the
>     Charles> gdk.POINTER_MOTION_HINT_MASK to enable passive mouse
>     Charles> motion event handling.  The gtk interface does not lag
>     Charles> behind with this enabled, even with complex figures.
>     Charles> Does this break functionality you are expecting somewhere
>     Charles> else?  Now the gtk backend acts the same as wx and tk
>     Charles> with respect to mouse motion.  Here is the reference I
>     Charles> found for addressing this problem:
>     Charles> http://www.pygtk.org/pygtk2tutorial/sec-EventHandling.html#id3096656
> 
> 
> On my system, the performance is acceptable with this somewhat
> pathological test case
> 
> from pylab import *
> 
> for i in range(1,7):
>     subplot(3,2,i)
>     imshow(rand(1000,1000), interpolation='bicubic')
> show()
> 
> So I'm happy to keep it.
> 
> Nice work.  Steve Chaplin, btw, is the resident gtk expert, so he may
> weigh in on the gtk strategy...
> 
> JDH

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> 	draw_idle still seems to suffer from the "trying to
    Charles> catch up" problem.  I added the
    Charles> gdk.POINTER_MOTION_HINT_MASK to enable passive mouse
    Charles> motion event handling.  The gtk interface does not lag
    Charles> behind with this enabled, even with complex figures.
    Charles> Does this break functionality you are expecting somewhere
    Charles> else?  Now the gtk backend acts the same as wx and tk
    Charles> with respect to mouse motion.  Here is the reference I
    Charles> found for addressing this problem:
    Charles> http://www.pygtk.org/pygtk2tutorial/sec-EventHandling.html#id3096656


On my system, the performance is acceptable with this somewhat
pathological test case

from pylab import *

for i in range(1,7):
    subplot(3,2,i)
    imshow(rand(1000,1000), interpolation='bicubic')
show()

So I'm happy to keep it.

Nice work.  Steve Chaplin, btw, is the resident gtk expert, so he may
weigh in on the gtk strategy...

JDH

	draw_idle still seems to suffer from the "trying to catch up" problem.
 I added the gdk.POINTER_MOTION_HINT_MASK to enable passive mouse motion
event handling.  The gtk interface does not lag behind with this
enabled, even with complex figures.  Does this break functionality you
are expecting somewhere else?  Now the gtk backend acts the same as wx
and tk with respect to mouse motion.
	Here is the reference I found for addressing this problem:
http://www.pygtk.org/pygtk2tutorial/sec-EventHandling.html#id3096656

- Charlie

John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
>     Charles> 	I just committed code which adds a new kwarg to the
>     Charles> slider to allow for live updates while dragging.  It is
>     Charles> off by default since the gtk backend seems to queue
>     Charles> events.  Wx and tk work in a natural way (they don't
>     Charles> generate mouse events while busy).  Who is the resident
>     Charles> gtk expert, and do you think you know how to fix this?
>     Charles> It would be nice to have the live slider be on by
>     Charles> default.
> 
> The backend_bases.FigureCanvas defines a base method draw_idle which 
> calls draw by default
> 
>     def draw_idle(self, *args, **kwargs):
>         """
>         draw only if idle; defaults to draw but backends can overrride
>         """
>         self.draw(*args, **kwargs)
> 
> 
> backend_gtk subclasses this method to do proper idle drawing.  So call
> idle_draw from Slider.
> 
> Note that there are two updates to consider, the update of the slider
> and the update of the figure it is manipulating.  There is no reason
> not to continuously update the slider once you have this idle business
> sorted out.  But you probably do want to continuously update the
> figure it is modifying in every case, because the figure could be very
> complicated to draw.  Instead, you might want to expose this live
> update property as a checkbox in the slider, since if the figure is
> expensive (see examples/widgets/check_buttons.py and note you will
> have to update from CVS because I just committed a patch to make check
> buttons work for single buttons)
> 
> I've been working on how to draw individual artists w/o updating the
> entire figure.  This is mostly working with a few bugs in gtkagg.
> Basically you have to manage the background region as a memory chunk
> and then reblit the background before redrawing the artist.  This was
> designed to make animations faster and to support better GUI widgets.
> 
> The first example below shows how to draw just a rectangle and move it
> around the screen w/o updating the entire figure.  The second example
> is more complex, and makes a rectangle widget which you can move
> around the canvas or resize using a standard click on edge drag
> operation.  In this one, you create new rectangles by pressing "n"
> (only works on gtkagg).  Only two methods are required to support this
> on other backends
> 
>   region = canvas.copy_from_bbox(bbox)
>   canvas.restore_region(region)
>   canvas.blit(bbox)
> 
> This is all highly experimental and subject to change, but it maybe
> something you want to incorporate into the slider for better realtime
> updating.  Note that you can easily add copy_from_bbox and
> restore_region to cocoaagg by simply forwarding the calls onto the agg
> renderer, as gtkagg does.  For the blit method, you have to figure out
> how to make cocoa blit a region -- shouldn't be too hard.
> 
> JDH
> 
> ######## Example 1  #############
> 
> from pylab import *
> ion()
> ax = subplot(111)
> plot(rand(100), rand(100), 'o')
> 
> r = Rectangle((.5, .5), width=.1, height=.1)
> ax.add_patch(r)
> r.region = ax.figure.canvas.copy_from_bbox(r.get_window_extent())
> draw()
> def move(event):
>     if not move.idle or event.inaxes != ax: return
>     move.idle = 0
>     ax.figure.canvas.restore_region(r.region)
>     r.xy = event.xdata, event.ydata
>     r.region = ax.figure.canvas.copy_from_bbox(r.get_window_extent())
>     ax.draw_artist(r)
>     ax.figure.canvas.blit(ax.bbox)
>     move.idle = 1
> move.idle = 1
> connect('motion_notify_event', move)
> show()
> 
> 
> 
> ######## Example 2  #############
> from pylab import *
> from matplotlib.transforms import lbwh_to_bbox
> from matplotlib.mlab import dist_point_to_segment
> 
> class RectangleWidget(Rectangle):
>     def __init__(self, figure, *args, **kwargs):
>         Rectangle.__init__(self, *args, **kwargs)
>         self.figure = figure
>         self.idle = True
>         self.oldbox = self.get_window_extent()
>         self.newbox = self.get_window_extent()
>         
>         self.region = self.figure.canvas.copy_from_bbox(self.oldbox)
>         self.figure.canvas.mpl_connect('motion_notify_event', self.move)
>         self.figure.canvas.mpl_connect('button_press_event', self.press)
>         self.figure.canvas.mpl_connect('button_release_event', self.release)        
>         
>         self.figure.draw_artist(self)            
>         self._resize = False
>         self._drag = False
> 
>     def redraw(self):
>         canvas = self.figure.canvas
>         canvas.restore_region(self.region)
>         self.region = canvas.copy_from_bbox(self.newbox)
>         self.figure.draw_artist(self)            
>         canvas.blit(self.oldbox)
>         canvas.blit(self.newbox)
>         
>     def press(self, event):
>         if event.button!=1: return
>         x, y = self.xy
>         w, h = self.width, self.height
>         # the four line segments of the rectangle
>         lb = x, y
>         lt = x, y+h
>         rb = x+w, y
>         rt = x+w, y+h
>         segments = {
>             'left'   : (lb, lt),
>             'right'  : (rb, rt),
>             'top'    : (lt, rt),
>             'bottom' : (lb, rb),
>             }
>         p = event.x, event.y
>         near = []
>         for name, segment in segments.items():
>             s0, s1 = segment
>             d = dist_point_to_segment(p, s0, s1)
>             if d<5: near.append(name)
> 
>         info = event.x, event.y, self.xy[0], self.xy[1], self.width, self.height, near
>         if len(near):
>             self._resize = info
>             self.set_edgecolor('red')
>             self.set_linewidth(2)
>         else:
>             self._resize = False
>             if self.get_window_extent().contains(event.x, event.y):
>                 self._drag = info
>         self.redraw()
> 
>     def release(self, event):
>         if event.button!=1: return
>         self._resize = False
>         self._drag = False
>         self.idle = True
>         self.set_edgecolor('black')
>         self.set_linewidth(0.5)
>         self.redraw()
>         
>     def move(self, event):
>         if not (self.idle and (self._resize or self._drag)): return 
> 
>         self.idle = False
>         canvas = self.figure.canvas
>         if self._resize:
>             exo, eyo, xo, yo, wo, ho, near = self._resize
>         else:
>             exo, eyo, xo, yo, wo, ho, near = self._drag
> 
>         scalex=0; scaley=0; scalew=0; scaleh=0
>         if 'left' in near:
>             scalex = 1
>             scalew = -1
>         if 'right' in near:
>             scalew = 1
>         if 'bottom' in near:
>             scaley = 1
>             scaleh = -1
>         if 'top' in near:
>             scaleh = 1
> 
>         if self._drag:
>             scalex = 1
>             scaley = 1
>         
>         dx = event.x - exo
>         dy = event.y - eyo
>         if event.button ==1:
>             self.oldbox = self.get_padded_box()
> 
>             newx = xo + scalex*dx
>             if scalew==0 or newx<xo+wo:
>                 self.xy[0] = newx
>             newy = yo + scaley*dy
>             if scaleh==0 or newy<yo+ho:
>                 self.xy[1] = newy
> 
>             neww = wo + scalew*dx
>             if neww>0: self.width = neww
>             
>             newh = ho + scaleh*dy
>             if newh>0: self.height = newh
>             
>             #self.xy = event.x, event.y
>             self.newbox = self.get_padded_box()
>             #print event.x, event.y, self.get_padded_box().get_bounds()
>             self.redraw()
>         self.idle = True
> 
>     def get_padded_box(self, pad=5):
>         xmin = self.xy[0]-pad
>         ymin = self.xy[1]-pad
>         return lbwh_to_bbox(xmin, ymin, self.width+2*pad, self.height+2*pad)
>         
>         
>         
> ion()    
> fig = figure()
> #ax = subplot(111)
> 
> def keypress(event):
>     if event.key=='n':
>         widget = RectangleWidget( fig, (100,100), 20, 30)
>         fig.canvas.blit()
> 
> fig.canvas.mpl_connect('key_press_event', keypress)
> 
> show()
> 

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> 	I just committed code which adds a new kwarg to the
    Charles> slider to allow for live updates while dragging.  It is
    Charles> off by default since the gtk backend seems to queue
    Charles> events.  Wx and tk work in a natural way (they don't
    Charles> generate mouse events while busy).  Who is the resident
    Charles> gtk expert, and do you think you know how to fix this?
    Charles> It would be nice to have the live slider be on by
    Charles> default.

The backend_bases.FigureCanvas defines a base method draw_idle which 
calls draw by default

    def draw_idle(self, *args, **kwargs):
        """
        draw only if idle; defaults to draw but backends can overrride
        """
        self.draw(*args, **kwargs)


backend_gtk subclasses this method to do proper idle drawing.  So call
idle_draw from Slider.

Note that there are two updates to consider, the update of the slider
and the update of the figure it is manipulating.  There is no reason
not to continuously update the slider once you have this idle business
sorted out.  But you probably do want to continuously update the
figure it is modifying in every case, because the figure could be very
complicated to draw.  Instead, you might want to expose this live
update property as a checkbox in the slider, since if the figure is
expensive (see examples/widgets/check_buttons.py and note you will
have to update from CVS because I just committed a patch to make check
buttons work for single buttons)

I've been working on how to draw individual artists w/o updating the
entire figure.  This is mostly working with a few bugs in gtkagg.
Basically you have to manage the background region as a memory chunk
and then reblit the background before redrawing the artist.  This was
designed to make animations faster and to support better GUI widgets.

The first example below shows how to draw just a rectangle and move it
around the screen w/o updating the entire figure.  The second example
is more complex, and makes a rectangle widget which you can move
around the canvas or resize using a standard click on edge drag
operation.  In this one, you create new rectangles by pressing "n"
(only works on gtkagg).  Only two methods are required to support this
on other backends

  region = canvas.copy_from_bbox(bbox)
  canvas.restore_region(region)
  canvas.blit(bbox)

This is all highly experimental and subject to change, but it maybe
something you want to incorporate into the slider for better realtime
updating.  Note that you can easily add copy_from_bbox and
restore_region to cocoaagg by simply forwarding the calls onto the agg
renderer, as gtkagg does.  For the blit method, you have to figure out
how to make cocoa blit a region -- shouldn't be too hard.

JDH

######## Example 1  #############

from pylab import *
ion()
ax = subplot(111)
plot(rand(100), rand(100), 'o')

r = Rectangle((.5, .5), width=.1, height=.1)
ax.add_patch(r)
r.region = ax.figure.canvas.copy_from_bbox(r.get_window_extent())
draw()
def move(event):
    if not move.idle or event.inaxes != ax: return
    move.idle = 0
    ax.figure.canvas.restore_region(r.region)
    r.xy = event.xdata, event.ydata
    r.region = ax.figure.canvas.copy_from_bbox(r.get_window_extent())
    ax.draw_artist(r)
    ax.figure.canvas.blit(ax.bbox)
    move.idle = 1
move.idle = 1
connect('motion_notify_event', move)
show()



######## Example 2  #############
from pylab import *
from matplotlib.transforms import lbwh_to_bbox
from matplotlib.mlab import dist_point_to_segment

class RectangleWidget(Rectangle):
    def __init__(self, figure, *args, **kwargs):
        Rectangle.__init__(self, *args, **kwargs)
        self.figure = figure
        self.idle = True
        self.oldbox = self.get_window_extent()
        self.newbox = self.get_window_extent()
        
        self.region = self.figure.canvas.copy_from_bbox(self.oldbox)
        self.figure.canvas.mpl_connect('motion_notify_event', self.move)
        self.figure.canvas.mpl_connect('button_press_event', self.press)
        self.figure.canvas.mpl_connect('button_release_event', self.release)        
        
        self.figure.draw_artist(self)            
        self._resize = False
        self._drag = False

    def redraw(self):
        canvas = self.figure.canvas
        canvas.restore_region(self.region)
        self.region = canvas.copy_from_bbox(self.newbox)
        self.figure.draw_artist(self)            
        canvas.blit(self.oldbox)
        canvas.blit(self.newbox)
        
    def press(self, event):
        if event.button!=1: return
        x, y = self.xy
        w, h = self.width, self.height
        # the four line segments of the rectangle
        lb = x, y
        lt = x, y+h
        rb = x+w, y
        rt = x+w, y+h
        segments = {
            'left'   : (lb, lt),
            'right'  : (rb, rt),
            'top'    : (lt, rt),
            'bottom' : (lb, rb),
            }
        p = event.x, event.y
        near = []
        for name, segment in segments.items():
            s0, s1 = segment
            d = dist_point_to_segment(p, s0, s1)
            if d<5: near.append(name)

        info = event.x, event.y, self.xy[0], self.xy[1], self.width, self.height, near
        if len(near):
            self._resize = info
            self.set_edgecolor('red')
            self.set_linewidth(2)
        else:
            self._resize = False
            if self.get_window_extent().contains(event.x, event.y):
                self._drag = info
        self.redraw()

    def release(self, event):
        if event.button!=1: return
        self._resize = False
        self._drag = False
        self.idle = True
        self.set_edgecolor('black')
        self.set_linewidth(0.5)
        self.redraw()
        
    def move(self, event):
        if not (self.idle and (self._resize or self._drag)): return 

        self.idle = False
        canvas = self.figure.canvas
        if self._resize:
            exo, eyo, xo, yo, wo, ho, near = self._resize
        else:
            exo, eyo, xo, yo, wo, ho, near = self._drag

        scalex=0; scaley=0; scalew=0; scaleh=0
        if 'left' in near:
            scalex = 1
            scalew = -1
        if 'right' in near:
            scalew = 1
        if 'bottom' in near:
            scaley = 1
            scaleh = -1
        if 'top' in near:
            scaleh = 1

        if self._drag:
            scalex = 1
            scaley = 1
        
        dx = event.x - exo
        dy = event.y - eyo
        if event.button ==1:
            self.oldbox = self.get_padded_box()

            newx = xo + scalex*dx
            if scalew==0 or newx<xo+wo:
                self.xy[0] = newx
            newy = yo + scaley*dy
            if scaleh==0 or newy<yo+ho:
                self.xy[1] = newy

            neww = wo + scalew*dx
            if neww>0: self.width = neww
            
            newh = ho + scaleh*dy
            if newh>0: self.height = newh
            
            #self.xy = event.x, event.y
            self.newbox = self.get_padded_box()
            #print event.x, event.y, self.get_padded_box().get_bounds()
            self.redraw()
        self.idle = True

    def get_padded_box(self, pad=5):
        xmin = self.xy[0]-pad
        ymin = self.xy[1]-pad
        return lbwh_to_bbox(xmin, ymin, self.width+2*pad, self.height+2*pad)
        
        
        
ion()    
fig = figure()
#ax = subplot(111)

def keypress(event):
    if event.key=='n':
        widget = RectangleWidget( fig, (100,100), 20, 30)
        fig.canvas.blit()

fig.canvas.mpl_connect('key_press_event', keypress)

show()

I found a solution on google which required altering the gtk backend.
Live sliders are on by default now, so let me know if any backends
break.  Wx, Tk, and Gtk all seem to work for me.

Charles Moad wrote:
> 	I just committed code which adds a new kwarg to the slider to allow for
> live updates while dragging.  It is off by default since the gtk backend
> seems to queue events.  Wx and tk work in a natural way (they don't
> generate mouse events while busy).  Who is the resident gtk expert, and
> do you think you know how to fix this?  It would be nice to have the
> live slider be on by default.
> 
> - Charlie
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

	I just committed code which adds a new kwarg to the slider to allow for
live updates while dragging.  It is off by default since the gtk backend
seems to queue events.  Wx and tk work in a natural way (they don't
generate mouse events while busy).  Who is the resident gtk expert, and
do you think you know how to fix this?  It would be nice to have the
live slider be on by default.

- Charlie

I resynced and still had the problem.  I committed this change which
makes everything happy for me.

cvs diff: Diffing .
Index: _backend_agg.cpp
===================================================================
RCS file: /cvsroot/matplotlib/matplotlib/src/_backend_agg.cpp,v
retrieving revision 1.81
diff -r1.81 _backend_agg.cpp
677c677
<   agg::rect<int> rect( (int)l, height-(int)t, (int)r, height-(int)b ) ;
---
>   agg::rect rect( (int)l, height-(int)t, (int)r, height-(int)b ) ;
Index: _backend_agg.h
===================================================================
RCS file: /cvsroot/matplotlib/matplotlib/src/_backend_agg.h,v
retrieving revision 1.22
diff -r1.22 _backend_agg.h
162c162
<   agg::rect<int> bbox_to_rect( const Py::Object& o);
---
>   agg::rect bbox_to_rect( const Py::Object& o);


- Charlie

John Hunter wrote:
>>>>>>"Charles" == Charles Moad <cm...@in...> writes:
> 
> 
>     Charles> CVS is giving compile errors in several of the cpp
>     Charles> backend files: error: `agg::rect' is not a template
> 
>     Charles> I think these should be `agg::rect_base' instead.
>     Charles> Changing that makes it compile fine.  Since I have never
>     Charles> messed with these files I thought I would post to the
>     Charles> list instead of committing the changes myself.
> 
> 
> In agg23/include/agg_basics.h you have
> 
>   typedef rect_base<int>    rect;   //----rec
> 
> So its either 
> 
>   agg::rect r;
> 
> or
> 
>   agg::rect_base<int> r;
> 
> 
> But strangely, I am not encountering any compile problems on my end.
> I did a fair amount of work in the agg backend yesterday, I just
> committed my tree, It may be that this problem will disappear after
> you resync.  If not, feel free to commit any needed fixes.
> 
> Thanks,
> JDH

John Hunter a =E9crit :

>>>>>>"Paul" =3D=3D Paul Cristini <pau...@un...> writes:
>>>>>>           =20
>>>>>>
>
>    Paul> you use PickBigLine.  Basically, PickBigLine evaluates the
>    Paul> orthogonal distance from the selected point to the line by
>    Paul> calculating the intersection between the line you want to
>    Paul> select and a line passing through the selected point which
>    Paul> is orthogonal.  Here is a modified version of PickBigLine
>    Paul> taking into account your remarks and working with Matplotlib
>    Paul> 0.82.
>
>Hi Paul,=20
>
>OK, at least now I understand what the problem is.  The current Axes
>picker works on line vertices and not individual segments, so if you
>zoom in on a segment and click on it you may not be near any of the
>vertices.  There is a similar problem with picking on polygons.
>Ideally, you want to iterate over all the segments in the lines and
>return the minimum distance to a segment (note there is a method
>matplotlib.mlab.dist_point_to_segment which computes this distance).
>For polygons, you would want to implement a test of insidedness.=20
>
>I thought about this when implementing the pick method but was afraid
>of the case when you have lots of segments; things could get really
>slow if you have a line with 10000 points unless you wrote some
>special purpose extension code.
>
>I do not think a separate "pick big line method" is needed here.
>Perhaps it makes more sense to add a flag to the pick method which
>either does it the correct and potentially slow way (useverts=3DFalse or
>something like that) or just picks on the vertices which is fast.  For
>dense lines, picking on the vertices works fine, but as you note this
>condition isn't always true.
>
>    Paul> My interests are in ray tracing in geophysics. I am
>    Paul> generating a lot of lines (thousands of) and then I need
>    Paul> after zooming to identify trajectories connecting a source
>    Paul> and a receiver . For example when I am picking a line I need
>    Paul> to know to what beam it belongs and also to what ray it
>    Paul> coresponds (two integers for instance) which is something I
>    Paul> know when I am plotting the line.  I don't know how to do it
>    Paul> with the label property. It is an axes property not a line2D
>    Paul> property.  If you want I can give an example of the use of
>    Paul> the tag property I add.
>
>An example would help.
>
>Of course, in python, you can "tag" anything you want
>
>    ax =3D subplot(111)
>    ax.myinitials =3D 'JDH'
>
>    line, =3D ax.plot([1,2,3])
>    line.mydata =3D ('Hi', 23)
>
>So it is questionable whether adding a "tag" attribute in particular
>is helpful.
>
>JDH
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcli=
ck
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> =20
>
You're right I did some tests taking into account your remarks and it
works well. I agree the tag method is not helpfull and I can do without
it. I also agree that a separate method for picking is not needed a flag
just as you suggested will be enough. The mlab.dist_point_to_segment
provides exactly the same results as what I wrote in the PickBigLine.
Thanks a lot for your advices
Paul

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> CVS is giving compile errors in several of the cpp
    Charles> backend files: error: `agg::rect' is not a template

    Charles> I think these should be `agg::rect_base' instead.
    Charles> Changing that makes it compile fine.  Since I have never
    Charles> messed with these files I thought I would post to the
    Charles> list instead of committing the changes myself.


In agg23/include/agg_basics.h you have

  typedef rect_base<int>    rect;   //----rec

So its either 

  agg::rect r;

or

  agg::rect_base<int> r;


But strangely, I am not encountering any compile problems on my end.
I did a fair amount of work in the agg backend yesterday, I just
committed my tree, It may be that this problem will disappear after
you resync.  If not, feel free to commit any needed fixes.

Thanks,
JDH

CVS is giving compile errors in several of the cpp backend files:

error: `agg::rect' is not a template

I think these should be `agg::rect_base' instead.  Changing that makes
it compile fine.  Since I have never messed with these files I thought I
would post to the list instead of committing the changes myself.

- Charlie

    Paul> The code just draw two lines a big one and a small one. The
    Paul> classical pick method works prefectly if you do not do a
    Paul> zoom to see the small line. But if you do it to see more
    Paul> accurately this small line then it is impossible to pick the
    Paul> big line unless you use PickBigLine.  Basically, PickBigLine
    Paul> evaluates the orthogonal distance from the selected point to
    Paul> the line by calculating the intersection between the line
    Paul> you want to select

Hi Paul, 

OK, at least now I understand what the problem is.  The current Axes
picker works on line vertices and not individual segments, so if you
zoom in on a segment and click on it you may not be near any of the
vertices.  There is a similar problem with picking on polygons.
Ideally, you want to iterate over all the segments in the lines and
return the minimum distance to a segment (note there is a method
matplotlib.mlab.dist_point_to_segment which computes this distance).
For polygons, you would want to implement a test of insidedness. 

I thought about this when implementing the pick method but was afraid
of the case when you have lots of segments; things could get really
slow if you have a line with 10000 points unless you wrote some
special purpose extension code.

I do not think a separate "pick big line method" is needed here.
Perhaps it makes more sense to add a flag to the pick method which
either does it the correct and potentially slow way (useverts=False or
something like that) or just picks on the vertices which is fast.  For
dense lines, picking on the vertices works fine, but as you note this
condition isn't always true.

    Paul> My interests are in ray tracing in geophysics. I am
    Paul> generating a lot of lines (thousands of) and then I need
    Paul> after zooming to identify trajectories connecting a source
    Paul> and a receiver . For example when I am picking a line I need
    Paul> to know to what beam it belongs and also to what ray it
    Paul> coresponds (two integers for instance) which is something I
    Paul> know when I am plotting the line.  I don't know how to do it
    Paul> with the label property. It is an axes property not a line2D
    Paul> property.  If you want I can give an example of the use of
    Paul> the tag property I add.

An example would help.

Of course, in python, you can "tag" anything you want

    ax = subplot(111)
    ax.myinitials = 'JDH'

    line, = ax.plot([1,2,3])
    line.mydata = ('Hi', 23)

So it is questionable whether adding a "tag" attribute in particular
is helpful.

JDH

>>>>> "Paul" == Paul Cristini <pau...@un...> writes:

    Paul> you use PickBigLine.  Basically, PickBigLine evaluates the
    Paul> orthogonal distance from the selected point to the line by
    Paul> calculating the intersection between the line you want to
    Paul> select and a line passing through the selected point which
    Paul> is orthogonal.  Here is a modified version of PickBigLine
    Paul> taking into account your remarks and working with Matplotlib
    Paul> 0.82.

Hi Paul, 

OK, at least now I understand what the problem is.  The current Axes
picker works on line vertices and not individual segments, so if you
zoom in on a segment and click on it you may not be near any of the
vertices.  There is a similar problem with picking on polygons.
Ideally, you want to iterate over all the segments in the lines and
return the minimum distance to a segment (note there is a method
matplotlib.mlab.dist_point_to_segment which computes this distance).
For polygons, you would want to implement a test of insidedness. 

I thought about this when implementing the pick method but was afraid
of the case when you have lots of segments; things could get really
slow if you have a line with 10000 points unless you wrote some
special purpose extension code.

I do not think a separate "pick big line method" is needed here.
Perhaps it makes more sense to add a flag to the pick method which
either does it the correct and potentially slow way (useverts=False or
something like that) or just picks on the vertices which is fast.  For
dense lines, picking on the vertices works fine, but as you note this
condition isn't always true.

    Paul> My interests are in ray tracing in geophysics. I am
    Paul> generating a lot of lines (thousands of) and then I need
    Paul> after zooming to identify trajectories connecting a source
    Paul> and a receiver . For example when I am picking a line I need
    Paul> to know to what beam it belongs and also to what ray it
    Paul> coresponds (two integers for instance) which is something I
    Paul> know when I am plotting the line.  I don't know how to do it
    Paul> with the label property. It is an axes property not a line2D
    Paul> property.  If you want I can give an example of the use of
    Paul> the tag property I add.

An example would help.

Of course, in python, you can "tag" anything you want

    ax = subplot(111)
    ax.myinitials = 'JDH'

    line, = ax.plot([1,2,3])
    line.mydata = ('Hi', 23)

So it is questionable whether adding a "tag" attribute in particular
is helpful.

JDH

Forgot the previous message, I did a bad manipulation

John,

Sorry for the late answer but I had problems in designing a simple example ( I had the very bad idea to choose letter "l" as the key to press) and also lots of other things to do. Here it is :

############################################################################
from pylab import *

def pick(event):
    if event.key=='p' and event.inaxes is not None:
        ax=event.inaxes
        a=ax.pick(event.x,event.y)
        a.set_color('g')
        a.set_linewidth(2.)
        draw()
    if event.key=='m' and event.inaxes is not None:
        ax=event.inaxes
        a=ax.pickBigLine(event.x,event.y)
        a.set_color('g')
        a.set_linewidth(2.)
        draw()
############################################################################
def PlotTwoLines():
    plot([0.,0.],[-100.,100.])
    plot([2.,2.],[-1.,1.])
    connect('key_press_event',pick)
    xmin,xmax,ymin,ymax=axis()
    axis([xmin-1.,xmax+1.,ymin*1.1,ymax*1.1])
    show()
if __name__=='__main__':
        PlotTwoLines()
#################################################################################

In this simple program, there is two way for picking a line, the classical pick method associated to the "p" key and PickBigLine method bassociated to the "m" key.
The code just draw two lines a big one and a small one. The classical pick method works prefectly if you do not do a zoom to see the small line. But if you do it to see more accurately this small line then it is impossible to pick the big line unless you use PickBigLine.
Basically, PickBigLine evaluates the orthogonal distance from the selected point to the line by calculating the intersection between the line you want to select
and a line passing through the selected point which is orthogonal.
Here is a modified version of PickBigLine taking into account your remarks and working with Matplotlib 0.82.

--------------------------------------------------------------------------------------------------
    def pickBigLine(self, x, y, trans=None):
        """
        Return the Line artist under point that is closest to the x, y.  if trans
        is None, x, and y are in window coords, 0,0 = lower left.  Otherwise,
        trans is a matplotlib transform that specifies the coordinate system
        of x, y.
        Calculates the orthogonal distance to the line
        Note this algorithm calculates distance to the vertices of the
        polygon, so if you want to pick a patch, click on the edge!
        """
        if trans is not None:
            xywin = trans.xy_tup((x,y))
        else:
            xywin = x,y

        def dist(a):
            Cste=1.e6    
            xdata = a.get_xdata(valid_only = True)
            ydata = a.get_ydata(valid_only = True)
            # A point is not a line
            if len(xdata) == 1: return Cste
            xt, yt = a.get_transform().numerix_x_y(xdata, ydata)
            xc, yc = xt[1]-xt[0], yt[1]-yt[0]
            if (xc==0.0 and yc == 0.0): return Cste
            D  = xc*xc + yc*yc
            D1 = -(xt[0]-xywin[0])*yc+(yt[0]-xywin[1])*xc
            D2 = -(yt[0]-xywin[1])*yc-(xt[0]-xywin[0])*xc
            if D2/D>1.00001 or D2/D<-0.00001: return Cste
            return abs(D1/sqrt(D))

        artists = self.lines
   
        if not len(artists): return None
        ds = [ (dist(a),a) for a in artists]
        ds.sort()
        return ds[0][1]
------------------------------------------------------------------------------------

My interests are in ray tracing in geophysics. I am generating a lot of lines
(thousands of) and then I need after zooming to identify  trajectories connecting a
source and a receiver . For example when I am picking a line I need to know to
what beam it belongs and also to what ray it coresponds (two integers for
instance) which is something I know when I am plotting the line.
I don't know how to do it with the label property. It is an axes
property not a line2D property.
If you want I can give an example of the use of the tag property I add.

Paul

John Hunter wrote:

>>>>>>"paul" =3D=3D paul cristini <pau...@un...> writes:
>
>
>    paul> The pick method because of the need to click on edges did
>    paul> not fullfill my needs. So I wrote a new method Called
>    paul> PickBigLine that does not required a mouse click close to
>    paul> the edge but close to the line you want to pick. This is
>    paul> particularly useful after zooming when the edges are
>    paul> sometimes out of the axis limits. =20
>
>Hi Paul,
>
>It is not clear to me what this method is for.  It would help if you
>posted an example where the current pick functionality failed and the
>one you propose succeeds (perhaps you could define your function at
>the top of the file for ease of use).
>
>I have a couple of questions/comments about your code...
>
>            xt, yt =3D a.get_transform().numerix_x_y(xdata, ydata)
>            xt, yt =3D asarray(xt), asarray(yt)=20
>
>There is no need to call asarray since numerix_x_y returns arrays.
>
>
>          =20
>            xc, yc =3D xt[1]-xt[0], yt[1]-yt[0]
>
>What is the point of this?  Why do you only look at the points xt[1],
>xt[0], yt[1], yt[0]?  What if someone needs to click on another point
>of the line?
>
>            if xc=3D=3D0.0 and yc =3D=3D 0.0: return 1000000.
>            D  =3D xc*xc + yc*yc
>            D1 =3D -(xt[0]-xywin[0])*yc+(yt[0]-xywin[1])*xc             =
         =20
>            D2 =3D -(yt[0]-xywin[1])*yc-(xt[0]-xywin[0])*xc
>
>What do D1 and D2 represent?  I'm having trouble understanding why,
>for example, you need to do (xt[0]-xywin[0])*yc
>
>            if D2/D>1.001 or D2/D<-0.001: return 1000000.
>
>I think the 1000000.0 sentinel value should be renamed to some useful
>constant name so it will be self documenting.
>
>            return abs(D1/D)
>
>
>        artists =3D self.lines
>        if not len(artists): return None
>        ds =3D [ (dist(a),a) for a in artists]
>        ds.sort()
>        return ds[0][1]
>
>
>    paul> I also needed to add a
>    paul> new property to Line2D called tag (similar to matlab) for
>    paul> sorting purposes. I wonder if you have thought of adding
>    paul> such a possibility to some objects for which it can be very
>    paul> useful.
>
>Does the "label" property help here.  Could you give a use case?
>
>Thanks!
>
>JDH
>
Sorry for the late answer but I had problems in designing a simple exampl=
e( I
had the very bad idea to letter "l" tas a key to press). Here it is :

from pylab import *

def pick(event):
    if event.key=3D=3D'p' and event.inaxes is not None:
        ax=3Devent.inaxes
        a=3Dax.pick(event.x,event.y)
        a.set_color('g')
        a.set_linewidth(2.)
        draw()
    if event.key=3D=3D'm' and event.inaxes is not None:
        ax=3Devent.inaxes
        a=3Dax.pickBigLine(event.x,event.y)
        a.set_color('g')
        a.set_linewidth(2.)
        draw()
#########################################################################=
###
def PlotTwoLines():
#     hold(True)
    plot([0.,0.],[-100.,100.])
    plot([2.,2.],[-1.,1.])
    connect('key_press_event',pick)
    xmin,xmax,ymin,ymax=3Daxis()
    axis([xmin-1.,xmax+1.,ymin*1.1,ymax*1.1])
    show()
if __name__=3D=3D'__main__':
        PlotTwoLines()

Two way for picking a line the classical pick method by using the "p"key =
and
PickBigLine by using the "m" key.
The code just draw two lines a big one and a small one. The classical pic=
k
method works prefectly if you do not zoom to see the small line. But if y=
ou do a
zoom
to see more accurately the small line then it is impossible to pick the b=
ig line
unless you use PickBigLine.
Basically, PickBigLine evaluates the orthogonal distance from the selecte=
d point
to the line by calculating the intersection between the line you want to =
select
and a line passing through the selected point which is orthogonal.
Here is a modified version of PickBigLine taking into account your remark=
s and
working with Matplotlib 0.82
-------------------------------------------------------------------------=
-------------------------
    def pickBigLine(self, x, y, trans=3DNone):
        """
        Return the Line artist under point that is closest to the x, y.  =
if trans
        is None, x, and y are in window coords, 0,0 =3D lower left.  Othe=
rwise,
        trans is a matplotlib transform that specifies the coordinate sys=
tem
        of x, y.
    Calculates the orthogonal distance to the line
        Note this algorithm calculates distance to the vertices of the
        polygon, so if you want to pick a patch, click on the edge!
        """
        if trans is not None:
            xywin =3D trans.xy_tup((x,y))
        else:
            xywin =3D x,y

        def dist(a):
        Cste=3D1.e6
            xdata =3D a.get_xdata(valid_only =3D True)
            ydata =3D a.get_ydata(valid_only =3D True)
        # A point is not a line
        if len(xdata) =3D=3D 1: return Cste
            xt, yt =3D a.get_transform().numerix_x_y(xdata, ydata)
        xc, yc =3D xt[1]-xt[0], yt[1]-yt[0]
        if (xc=3D=3D0.0 and yc =3D=3D 0.0): return Cste
        D  =3D xc*xc + yc*yc
        D1 =3D -(xt[0]-xywin[0])*yc+(yt[0]-xywin[1])*xc
        D2 =3D -(yt[0]-xywin[1])*yc-(xt[0]-xywin[0])*xc
        if D2/D>1.00001 or D2/D<-0.00001: return Cste
            return abs(D1/sqrt(D))

        artists =3D self.lines
  =20
        if not len(artists): return None
        ds =3D [ (dist(a),a) for a in artists]
        ds.sort()
        return ds[0][1]
-------------------------------------------------------------------------=
-----------

My interests are in ray tracing in geophysics. I am generating a lot of l=
ines
(thousands of) and then I need by zooming to identify  trajectories conne=
cting a
source and a receiver. For example when I am picking a line I need to kno=
w to
what beam it belongs and also to what ray it coresponds (two integers for
instance). I don't know how to do it with the label property. It is an ax=
es
property not a line2D property.
If you want I can give an example of the use of the tag property I add.

Paul

>>>>> "Ted" == Ted Drain <ted...@jp...> writes:

    Ted> John, Is there anything special required to get the subplot
    Ted> configuration tool available from QtAgg?  I'm in the process
    Ted> of fixing that sizing problem reported last week and the only
    Ted> way to fix it was to change how the toolbar layout works so
    Ted> I'm mucking around in the toolbar right now.

    Ted> I guess I'll sync and take a look at the Gtk backend and see
    Ted> what happens in there...

Hi Ted,

It shouldn't be hard.  The subplot configuration toolbar is a pure
matplotlib widget so all it requires id for your toolbar to embed it
into a properly sized qt canvas.  This means your toolbar needs to
know how to make a canvas, so you need to subclass the toolbar gor
qtagg.  What I did for GTK was add a "_get_canvas(self, fig)" method
to the toolbar.  

The base class binds the new subplots.png button to
configure_subplots, which looks like this -- note the line marked with
the arrow

class NavigationToolbar2GTK(NavigationToolbar2, gtk.Toolbar):
   ...snip...


    def configure_subplots(self, button):
        toolfig = Figure(figsize=(6,3))
====>   canvas = self._get_canvas(toolfig)
        toolfig.subplots_adjust(top=0.9)
        tool =  SubplotTool(self.canvas.figure, toolfig)

        w = int (toolfig.bbox.width())
        h = int (toolfig.bbox.height())


        window = gtk.Window()
        window.set_title("Subplot Configuration Tool")
        window.set_default_size(w, h)
        vbox = gtk.VBox()
        window.add(vbox)
        vbox.show()

        canvas.show()
        vbox.pack_start(canvas, True, True)
        window.show()


    def _get_canvas(self, fig):
        return FigureCanvasGTK(fig)


Then in gtkagg, I subclass the toolbar with



class NavigationToolbar2GTKAgg(NavigationToolbar2GTK):
    def _get_canvas(self, fig):
        return FigureCanvasGTKAgg(fig)


You might want to try the same approach for qtagg.  Of course there is
no FigureCanvasQt, but this approach will make it easier if someone
wants to add a different renderer to Qt, eg QtCairo.

JDH

On Wed, 2005-06-15 at 09:22 -0500, John Hunter wrote: 
> >>>>> "Steve" == Steve Chaplin <ste...@ya...> writes:
> 
>     Steve> Figure.get_width_height() returns width, height as floats,
>     Steve> but isn't width, height of a Figure always integers, and
>     Steve> wouldn't it make sense to return these as integers?
> 
>     Steve> This would enable changing the code: width, height =
>     Steve> figure.get_width_height() width, height = int(width),
>     Steve> int(height)
> 
>     Steve> to simply: width, height = figure.get_width_height()
> 
> The width and height of a figure are width/height in inches * dpi, and
> both dpi and the width/height vars can be floats.  So no, these values
> don't have to be integers.  In the postscript backend, for example, it
> returns the width and height of the figure in points.  We could add a
> convenience kwarg to the method, since in practice it is usually used
> by GUI developers who want the dimensions in pixels
> 
>   w, h = fig.get_width_height(asinteger=True)
> 
> If you think this is a good idea, feel free to add it.
> 
> JDH
My understanding is, the frontend does all its calculations in floating
point and never uses fig.get_width_height() because its always dealing
width width, height in inches and dpi.

'grep' shows that fig.get_width_height() is not used by the frontend,
its only ever used by the backends so it does not really belong in
Figure it belongs it FigureCanvas.

The value of width/height in inches * dpi does not need to be integers,
but what about the ACTUAL width, height values that the backends
produce?
The backends will either draw to the display with width, height in
integer pixels, or create an output file png, ps, svg etc, which in most
(all?) cases will have integer width, height. 
Does it make sense having an output file 1200.8 x 900.6? What use is the
fractional point/pixel?

I ran './simple_plot.py -dAgg' with
"savefig('simple_plot.png', dpi=150.1)"
to see if I would get the theoretical 1200.8 x 900.6 images.

png and jpg gave 1200 x 900
for svg I used w,h in inches of 8.1, 6.1 (and the default 72 dpi)
the svg file says the width, height is 583.2, 439.2, yet gthumb
shows the image size as 583 x 439.

So there is definitely a float-to-integer conversion/truncation for
width, height taking place.

I suggest moving Figure.get_width_height() to
FigureCanvas.get_width_height() and returning integers. If a backend
really can produce float width, height it can simply override
get_width_height().

regards,
Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

John,
Is there anything special required to get the subplot configuration tool 
available from QtAgg?  I'm in the process of fixing that sizing problem 
reported last week and the only way to fix it was to change how the toolbar 
layout works so I'm mucking around in the toolbar right now.

I guess I'll sync and take a look at the Gtk backend and see what happens 
in there...

Ted

At 01:14 PM 6/15/2005, John Hunter wrote:

>What's new in 0.82
>
>Subplot configuration
>
>   All of the parameters of the subplots are now exposed at the rc,
>   pylab and API layout.  These are left, right, bottom, top, wspace
>   and hspace which control how the subplots are placed on the screen.
>   See figure.SubplotParams, figure.Figure.subplots_adjust and the
>   pylab method subplots_adjust and examples/subplots_adjust.py .  Also
>   added a GUI neutral widget for adjusting subplots, see
>   examples/subplot_toolbar.py.  There is a new toolbar button on GTK*,
>   WX* and TkAgg to launch the subplot configuration tool (which uses
>   the new matplotlib cross GUI classes discussed below).
>
>   This also makes it easier to make ganged plots -- see
>   examples/ganged_plots.py
>
>   Note this required a small change to how the toolbar on some GUIs
>   are imported; if you are using the mpl API in WXAgg and GTKAgg, see
>   API_CHANGES.
>
>GUI neutral widgets
>
>   Matplotlib now has cross-GUI widgets (buttons, check buttons, radio
>   buttons and sliders).  You have to manually create properly sized
>   Axes for them to live in, but otherwise they are pretty easy to use.
>   See examples/widgets/*.py and
>   http://matplotlib.sf.net/screenshots.html#slider_demo.  This makes
>   it easier to create interactive figures that run across backends.
>
>Cap and join style
>
>   Exposes line cap and join style via new rc params and Line2D
>   properties
>
>     lines.dash_joinstyle : miter        # miter|round|bevel
>     lines.dash_capstyle : butt          # butt|round|projecting
>     lines.solid_joinstyle : miter       # miter|round|bevel
>     lines.solid_capstyle : projecting   # butt|round|projecting
>
>Axes kwargs
>
>   All Axes properties are now exposed via kwargs, so you can do, for
>   example
>
>    subplot(111, xlabel='time', ylabel='volts', autoscale_on=False,
>            xlim=(-1,1), ylim =(0,10) )
>
>Small bugfixes and features:
>
>   Fixed a upper/right tick bug (thanks Baptiste), fixed invalid rc
>   docstring vis-a-vis aliases, fixed bug #1217637 in ticker.py and a
>   cleanup bug in usetex (thanks Darren), added Sean Richards hist bin
>   fix (see API_CHANGES)
>
>http://matplotlib.sf.net
>
>Enjoy!
>JDH
>
>
>-------------------------------------------------------
>SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>from IBM. Find simple to follow Roadmaps, straightforward articles,
>informative Webcasts and more! Get everything you need to get up to
>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>_______________________________________________
>Matplotlib-devel mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Ted Drain     Jet Propulsion Laboratory   ted...@jp...    

John Hunter wrote:
>>>>>>"Steve" == Steve Chaplin <ste...@ya...> writes:
> 
> 
>     Steve> Figure.get_width_height() returns width, height as floats,
>     Steve> but isn't width, height of a Figure always integers, and
>     Steve> wouldn't it make sense to return these as integers?
> 
>     Steve> This would enable changing the code: width, height =
>     Steve> figure.get_width_height() width, height = int(width),
>     Steve> int(height)
> 
>     Steve> to simply: width, height = figure.get_width_height()
> 
> The width and height of a figure are width/height in inches * dpi, and
> both dpi and the width/height vars can be floats.  So no, these values
> don't have to be integers.  In the postscript backend, for example, it
> returns the width and height of the figure in points.  We could add a
> convenience kwarg to the method, since in practice it is usually used
> by GUI developers who want the dimensions in pixels
> 
>   w, h = fig.get_width_height(asinteger=True)
> 
> If you think this is a good idea, feel free to add it.

Just to be nitpicky, isn't this a bit of API bloat, when a simple

w, h = map(int,fig.get_width_height())

does the job just fine?  And it's even less characters :)

Cheers,

f

What's new in 0.82

Subplot configuration

  All of the parameters of the subplots are now exposed at the rc,
  pylab and API layout.  These are left, right, bottom, top, wspace
  and hspace which control how the subplots are placed on the screen.
  See figure.SubplotParams, figure.Figure.subplots_adjust and the
  pylab method subplots_adjust and examples/subplots_adjust.py .  Also
  added a GUI neutral widget for adjusting subplots, see
  examples/subplot_toolbar.py.  There is a new toolbar button on GTK*,
  WX* and TkAgg to launch the subplot configuration tool (which uses
  the new matplotlib cross GUI classes discussed below).  

  This also makes it easier to make ganged plots -- see
  examples/ganged_plots.py

  Note this required a small change to how the toolbar on some GUIs
  are imported; if you are using the mpl API in WXAgg and GTKAgg, see
  API_CHANGES.

GUI neutral widgets

  Matplotlib now has cross-GUI widgets (buttons, check buttons, radio
  buttons and sliders).  You have to manually create properly sized
  Axes for them to live in, but otherwise they are pretty easy to use.
  See examples/widgets/*.py and
  http://matplotlib.sf.net/screenshots.html#slider_demo.  This makes
  it easier to create interactive figures that run across backends.

Cap and join style

  Exposes line cap and join style via new rc params and Line2D
  properties

    lines.dash_joinstyle : miter        # miter|round|bevel
    lines.dash_capstyle : butt          # butt|round|projecting
    lines.solid_joinstyle : miter       # miter|round|bevel
    lines.solid_capstyle : projecting   # butt|round|projecting

Axes kwargs

  All Axes properties are now exposed via kwargs, so you can do, for
  example

   subplot(111, xlabel='time', ylabel='volts', autoscale_on=False,
           xlim=(-1,1), ylim =(0,10) )

Small bugfixes and features:

  Fixed a upper/right tick bug (thanks Baptiste), fixed invalid rc
  docstring vis-a-vis aliases, fixed bug #1217637 in ticker.py and a
  cleanup bug in usetex (thanks Darren), added Sean Richards hist bin
  fix (see API_CHANGES)

http://matplotlib.sf.net

Enjoy!
JDH

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

    Steve> Figure.get_width_height() returns width, height as floats,
    Steve> but isn't width, height of a Figure always integers, and
    Steve> wouldn't it make sense to return these as integers?

    Steve> This would enable changing the code: width, height =
    Steve> figure.get_width_height() width, height = int(width),
    Steve> int(height)

    Steve> to simply: width, height = figure.get_width_height()

The width and height of a figure are width/height in inches * dpi, and
both dpi and the width/height vars can be floats.  So no, these values
don't have to be integers.  In the postscript backend, for example, it
returns the width and height of the figure in points.  We could add a
convenience kwarg to the method, since in practice it is usually used
by GUI developers who want the dimensions in pixels

  w, h = fig.get_width_height(asinteger=True)

If you think this is a good idea, feel free to add it.

JDH

Figure.get_width_height() returns width, height as floats,
but isn't width, height of a Figure always integers, and wouldn't it
make sense to return these as integers?

This would enable changing the code:
    width, height = figure.get_width_height()
    width, height = int(width), int(height)

to simply:
    width, height = figure.get_width_height()

Steve

Send instant messages to your online friends http://au.messenger.yahoo.com 

>>>>> "Charles" == Charles Moad <cm...@in...> writes:

    Charles> So I am going to go ahead and throw this one out.  It is
    Charles> by no means complete.

    Charles> http://euclid.uits.iupui.edu/~cmoad/CocoaAgg.tar.gz

Cool, I just go that working on Panther.  For those who want to try
it, I'll add to Charles instructions that you need to add CocoaAgg to
matplotlib/__init__.py and matplotlib/backends/__init__.py.

It looks nice!  Charles, the toolbar will be easier than you think,
since all you have to do is make the right connections to mouse press
event, motion notify event and so on.  If you set up the events, mpl
will do the rest.  Also, the save figure button doesn't seem to do
anything.  I assume this is just a place holder?

    Charles> There a lot of things I would like to do with this
    Charles> including using QTKit to dump a movie and adding
    Charles> clipboard support.  Long term, it would be nice to make
    Charles> the plots embeddable in an app.  

Sounds good -- keep up the good work!

JDH

So I am going to go ahead and throw this one out.  It is by no means  
complete.

http://euclid.uits.iupui.edu/~cmoad/CocoaAgg.tar.gz

     It requires PyObjC.  You need to put the nib file in the  
matplotlib data path.  On panther you can run a script with - 
dCocoaAgg and resize the native window.  Unfortunately tiger changed  
something with creating an imagerep and things aren't working quite  
right with it yet.
     You DO NOT have to use pythonw to run your scripts.
     There a lot of things I would like to do with this including  
using QTKit to dump a movie and adding clipboard support.  Long term,  
it would be nice to make the plots embeddable in an app.  Anyway, let  
me know if anyone is interested in working on this.

- Charlie