matplotlib-devel Mailing List for matplotlib (Page 2)

On Sun, Apr 25, 2010 at 1:28 PM, Neal Becker <ndb...@gm...> wrote:
> savefig works fine.
>
> Using 'gtk' backend I can save, but seems to have other problems.
>
> Using recommended TkAgg I get error that
> ImportError: No module named backend_tkagg
>
You will have to make some installations to bring TkAgg alive. I would
suggest trying also the Qt4Agg backend since KDE based on Qt. It is always a
good idea to use the package manager for these. Let me know if this helps.

Gökhan Sever wrote:
> On Sun, Apr 25, 2010 at 1:02 PM, Neal Becker
> <ndb...@gm...> wrote:
> 
>> Yes, I get this:
>>
>> kfilemodule(29192)/kio (KDirModel) KDirModelPrivate::_k_slotDeleteItems:
>> No node found for item that was just removed:
>> KUrl("file:///home/nbecker/test1.cs")
>> kfilemodule(29192): couldn't create slave: "Unable to create io-slave:
>> klauncher said: Unknown protocol ''.
>> "
>> kfilemodule(29192): couldn't create slave: "Unable to create io-slave:
>> klauncher said: Unknown protocol ''.
>> "
>>
> 
> Very specific KDE errors. Sorry can't comment on these errors.
> 
> 
>>
>> Have not tried savefig or other backend. (Have to learn how to use
>> savefig first)
>>
> 
> These are easy. Within IPython -pylab run your script with run myscript.py
> . Then do a plt.savefig("myplot.png") or whatever extension available to
> you. To change the backend go into your .matplotlib directory and edit
> matplotlibrc file. Find backend keyword and experiment with the available
> backends to see if you can reproduce that error.
> 
savefig works fine.
Using 'gtk' backend I can save, but seems to have other problems.
Using recommended TkAgg I get error that 
ImportError: No module named backend_tkagg

Hello,
The amplitude of sharp peaks is not shown correctly when several plots
are stitched together and the x scale becomes very large. I have
noticed this problem with the pdf and png backends in the attached
script.
Best regards,
Miguel

On Sun, Apr 25, 2010 at 1:02 PM, Neal Becker <ndb...@gm...> wrote:
> Yes, I get this:
>
> kfilemodule(29192)/kio (KDirModel) KDirModelPrivate::_k_slotDeleteItems: No
> node found for item that was just removed:
> KUrl("file:///home/nbecker/test1.cs")
> kfilemodule(29192): couldn't create slave: "Unable to create io-slave:
> klauncher said: Unknown protocol ''.
> "
> kfilemodule(29192): couldn't create slave: "Unable to create io-slave:
> klauncher said: Unknown protocol ''.
> "
>
Very specific KDE errors. Sorry can't comment on these errors.
>
> Have not tried savefig or other backend. (Have to learn how to use savefig
> first)
>
These are easy. Within IPython -pylab run your script with run myscript.py .
Then do a plt.savefig("myplot.png") or whatever extension available to you.
To change the backend go into your .matplotlib directory and edit
matplotlibrc file. Find backend keyword and experiment with the available
backends to see if you can reproduce that error.
-- 
Gökhan

Gökhan Sever wrote:
> On Sun, Apr 25, 2010 at 12:52 PM, Neal Becker
> <ndb...@gm...> wrote:
> 
>> Yes, I meant the 'save' button in the upper right.
>>
>> It used to work, but some update seems to have broken it. Strange, so
>> far the only application that shows a problem like this (and I do use a
>> lot of different apps!)
>>
> 
> Do you get any error messages behind the scenes? Does it work when you
> save the plot using savefig? Is it same with different backends? I am on
> GNOME. You seem to like using KDE, right?
> 
Yes, I get this:
kfilemodule(29192)/kio (KDirModel) KDirModelPrivate::_k_slotDeleteItems: No 
node found for item that was just removed: 
KUrl("file:///home/nbecker/test1.cs") 
kfilemodule(29192): couldn't create slave: "Unable to create io-slave:
klauncher said: Unknown protocol ''.
" 
kfilemodule(29192): couldn't create slave: "Unable to create io-slave:
klauncher said: Unknown protocol ''.
"
Yes, I am on KDE.
Have not tried savefig or other backend. (Have to learn how to use savefig 
first) 

On Sun, Apr 25, 2010 at 12:52 PM, Neal Becker <ndb...@gm...> wrote:
> Yes, I meant the 'save' button in the upper right.
>
> It used to work, but some update seems to have broken it. Strange, so far
> the only application that shows a problem like this (and I do use a lot of
> different apps!)
>
Do you get any error messages behind the scenes? Does it work when you save
the plot using savefig? Is it same with different backends? I am on GNOME.
You seem to like using KDE, right?
-- 
Gökhan

Gökhan Sever wrote:
> On Sun, Apr 25, 2010 at 12:33 PM, Neal Becker
> <ndb...@gm...> wrote:
> 
>> python-matplotlib-0.99.1.2-1.fc12.x86_64
>>
>> When I hit 'print' button, I get a partially painted dialog. Screenshot
>> attached. This is repeatable on 2 different machines.
>>
> 
> I am on Fedora 12. Where is print button in matplotlib? You meant the save
> dialog? If that's the case I don't see any problem using the svn version
> of mpl.
> 
> I build sources manually ->
> http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-svn
> 
> Similarly I build numpy and scipy from sources too. If available I use
> easy_install for some packages, otherwise mostly manual builds. (Except
> the Python itself.) This might be confusing since I use the package
> manager to install dependencies most of the time. Once in a while I see
> some packages requiring older numpy builds, also when I try to uninstall
> some packages via package manager it tries to uninstall more packages (the
> critical ones) than what is installed. Not always required but manual
> builds give more control and easy to manage on some occurrences like in
> matplotlib build case.
> 
Yes, I meant the 'save' button in the upper right.
It used to work, but some update seems to have broken it. Strange, so far 
the only application that shows a problem like this (and I do use a lot of 
different apps!)

On Sun, Apr 25, 2010 at 12:33 PM, Neal Becker <ndb...@gm...> wrote:
> python-matplotlib-0.99.1.2-1.fc12.x86_64
>
> When I hit 'print' button, I get a partially painted dialog. Screenshot
> attached. This is repeatable on 2 different machines.
>
I am on Fedora 12. Where is print button in matplotlib? You meant the save
dialog? If that's the case I don't see any problem using the svn version of
mpl.
I build sources manually ->
http://matplotlib.sourceforge.net/faq/installing_faq.html#install-from-svn
Similarly I build numpy and scipy from sources too. If available I use
easy_install for some packages, otherwise mostly manual builds. (Except the
Python itself.) This might be confusing since I use the package manager to
install dependencies most of the time. Once in a while I see some packages
requiring older numpy builds, also when I try to uninstall some packages via
package manager it tries to uninstall more packages (the critical ones) than
what is installed. Not always required but manual builds give more control
and easy to manage on some occurrences like in matplotlib build case.
-- 
Gökhan

python-matplotlib-0.99.1.2-1.fc12.x86_64
When I hit 'print' button, I get a partially painted dialog. Screenshot 
attached. This is repeatable on 2 different machines.

Eric, Tony, thanks for your replies. I'll look at SciPy then for this functionality.
Thanks,
--Michiel.
--- On Sat, 4/24/10, Eric Firing <ef...@ha...> wrote:
> From: Eric Firing <ef...@ha...>
> Subject: Re: [matplotlib-devel] Lowess smoothing
> To: "Michiel de Hoon" <mjl...@ya...>
> Cc: mat...@li...
> Date: Saturday, April 24, 2010, 2:29 PM
> Michiel de Hoon wrote:
> > Hi everybody,
> > 
> > A number of years ago I wrote a function to do Lowess
> smoothing to calculate a smooth curve through a scatter
> plot. I copied an example script below and attached the
> resulting figure to this mail.
> > I think that such a smoothing function would be a
> useful addition to matplotlib. Does anybody have any
> objections against me adding this to matplotlib? If not,
> what would be a suitable place to put this function?
> > 
> > --Michiel.
> > 
> 
> Michiel,
> 
> Certainly it would be good to have that function available,
> but I'm not in favor of putting it in mpl. The trend
> has been to try to reduce overlap among mpl, numpy, and
> scipy. To that end, scipy seems like the natural home
> for smoothing functions.
> 
> Eric
> 
> > 
> > from pylab import *
> > 
> > x = arange(0,10,0.01)
> > ytrue = exp(-x/5.0) + 2*sin(x/3.0)
> > 
> > # add random errors with a normal distribution 
>        
>   y = ytrue + normal(size=len(x))
> > scatter(x,y,color='cyan')
> > 
> > # calculate a smooth curve through the scatter plot
> > ys = smooth(x, y, 'lowess')
> > plot(x,ys,'red',linewidth=3)
> > 
> > # draw the true values for comparison
> > plot(x,ytrue,'green',linewidth=3)
> > 
> > 
> >    
> > 
> >
> ------------------------------------------------------------------------
> > 
> > 
> >
> ------------------------------------------------------------------------
> > 
> >
> ------------------------------------------------------------------------------
> > 
> > 
> >
> ------------------------------------------------------------------------
> > 
> > _______________________________________________
> > Matplotlib-devel mailing list
> > Mat...@li...
> > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> 
 

Michiel de Hoon wrote:
> Hi everybody,
> 
> A number of years ago I wrote a function to do Lowess smoothing to calculate a smooth curve through a scatter plot. I copied an example script below and attached the resulting figure to this mail.
> I think that such a smoothing function would be a useful addition to matplotlib. Does anybody have any objections against me adding this to matplotlib? If not, what would be a suitable place to put this function?
> 
> --Michiel.
> 
Michiel,
Certainly it would be good to have that function available, but I'm not 
in favor of putting it in mpl. The trend has been to try to reduce 
overlap among mpl, numpy, and scipy. To that end, scipy seems like the 
natural home for smoothing functions.
Eric
> 
> from pylab import *
> 
> x = arange(0,10,0.01)
> ytrue = exp(-x/5.0) + 2*sin(x/3.0)
> 
> # add random errors with a normal distribution 
> y = ytrue + normal(size=len(x))
> scatter(x,y,color='cyan')
> 
> # calculate a smooth curve through the scatter plot
> ys = smooth(x, y, 'lowess')
> plot(x,ys,'red',linewidth=3)
> 
> # draw the true values for comparison
> plot(x,ytrue,'green',linewidth=3)
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On Apr 24, 2010, at 4:25 AM, Michiel de Hoon wrote:
> Hi everybody,
> 
> A number of years ago I wrote a function to do Lowess smoothing to calculate a smooth curve through a scatter plot. I copied an example script below and attached the resulting figure to this mail.
> I think that such a smoothing function would be a useful addition to matplotlib. Does anybody have any objections against me adding this to matplotlib? If not, what would be a suitable place to put this function?
I'm not a matplotlib developer, but smoothing seems more appropriate for scipy. There's been some talk of starting a scikit for smoothing functions (see links below), but I'm not sure if anyone has the motivation to actually take the lead.
-Tony
http://mail.scipy.org/pipermail/scipy-user/2010-February/024402.html
http://mail.scipy.org/pipermail/scipy-user/2010-February/024408.html 

Hi everybody,
A number of years ago I wrote a function to do Lowess smoothing to calculate a smooth curve through a scatter plot. I copied an example script below and attached the resulting figure to this mail.
I think that such a smoothing function would be a useful addition to matplotlib. Does anybody have any objections against me adding this to matplotlib? If not, what would be a suitable place to put this function?
--Michiel.
from pylab import *
x = arange(0,10,0.01)
ytrue = exp(-x/5.0) + 2*sin(x/3.0)
# add random errors with a normal distribution 
y = ytrue + normal(size=len(x))
scatter(x,y,color='cyan')
# calculate a smooth curve through the scatter plot
ys = smooth(x, y, 'lowess')
plot(x,ys,'red',linewidth=3)
# draw the true values for comparison
plot(x,ytrue,'green',linewidth=3)
 

On Thu, Apr 22, 2010 at 4:40 PM, Sandro Tosi <mo...@de...> wrote:
> Hello all,
> in some time (let's say a couple of months, maybe more) Debian will
> enter the "freeze" period, where no new upstream releases are
> accepted, in order to prepare the best stable release we can :)
>
> In the past months I see many changes are accumulated in the SVN but
> no new release are done. I don't know if you've already discussed
> about releasing mpl, but it would be nice if we can have something
> before the freeze, so to have a quite-update mpl in squeeze.
>
> >From my POV, I'll provide all the support needed, so if there
> something I can do just tell me :)
Hey Sandro,
thanks for the head's up. We would like to get a 1.0 release out and
there are two roadbumps we have to navigate first. We'd like to
transition our VCS to git, and this impacts our release schedule
because of the "get_sample_data" support in the trunk which currently
pulls the data from svn but would have to be refactored to pull from
hit and we'd like to make the transition before we do a release.
Andrew, who is handling the git transition, has been very tied up of
late, but thinks he'll have some time in early May. The other issue
is my dead OSX build box -- I have access to a 64bit python 2.6
platform for builds for OSX, but currently no other platforms/versions
so I have to sink some time into this for a release, though this is
not a show stopper as we could do a release with incomplete binary
support for OSX.
So keep our feet to the fire and make sure we don't fall too far
behind so we can get something out before the freeze, hopefully far
enough before the freeze that we can get at least one bugfix release
out...
JDH

Hello all,
in some time (let's say a couple of months, maybe more) Debian will
enter the "freeze" period, where no new upstream releases are
accepted, in order to prepare the best stable release we can :)
In the past months I see many changes are accumulated in the SVN but
no new release are done. I don't know if you've already discussed
about releasing mpl, but it would be nice if we can have something
before the freeze, so to have a quite-update mpl in squeeze.
>From my POV, I'll provide all the support needed, so if there
something I can do just tell me :)
Regards,
-- 
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi

Manuel Metz wrote:
> Eric, I've seen the comment "Why is the copy needed?" that you've added
> to the axes' hist method. I think this was introduced by me some time
> ago. Indeed, I think it is not really needed. If I remember correctly, I
> had done the copying to avoid that the input x gets modified (I had bad
> experience with that before), but I think we can avoid it?
Manuel,
It turns out the problem was that 1-D arrays were being converted to 2-D 
by assigning to the shape attribute. (This is something I often do, but 
now I will be more cautious about it.) When done on the original input 
argument, which was returned by "x = np.asarray(x)", this had the side 
effect of changing that argument. Copying was preventing that. To 
avoid the copy, one could either make a new view of the argument 
explicitly, or do it implicitly by using the reshape method instead of 
assigning to the shape attribute. I chose the second option.
Eric

Eric Firing wrote:
> Jeff Whitaker wrote:
>> Eric Firing wrote:
>>> Jeff,
>>>
>>> Basemap methods like plot() include a "draw_if_interactive" command, 
>>> followed by a call to the set_axes_limits() method, which ends with
>>>
>>> # force draw if in interactive mode.
>>> if is_interactive():
>>> figManager = _pylab_helpers.Gcf.get_active()
>>> figManager.canvas.draw()
>>>
>>> It seems to me that you could eliminate all those 
>>> "draw_if_interactive" blocks from plot etc., and replace the end 
>>> block of set_axes_limits() with
>>>
>>> if is_interactive():
>>> import matplotlib.pyplot as plt
>>> plt.draw_if_interactive()
>>>
>>> The advantages would be reduced clutter in the drawing methods, and 
>>> consistent use of draw_if_interactive. I think the latter would 
>>> make interactive running of functions and subclasses built on 
>>> basemap more efficient by reducing redundant draw operations.
>>>
>>> It also looks like at least most of the operations in 
>>> set_axes_limits really need to be done only once (although I have 
>>> not checked this carefully). Instead of repeating them with every 
>>> call to a plotting method, the basemap instance could keep a list of 
>>> hashes of axes objects on which the operations have already been 
>>> run, and use that to prevent duplication.
>>>
>>> Nothing urgent here--just some ideas that occur to me while working 
>>> with basemap. If you think any are worth pursuing, and you want me 
>>> to take a shot at it, let me know.
>>>
>>> Eric
>>>
>>>
>>> 
>> Eric: You are right, that could be done much more efficiently. I'm 
>> stuck in the U.K. waiting for the volcanic dust to clear, so if you 
>> want to take a shot at it go ahead.
>>
>> -Jeff
>>
>
> Jeff,
>
> I made the changes, and removed a few obsolete bits.
>
> I hope you are cleared to fly soon, if you have not already departed.
>
> Eric
Eric: I'm still here - hope to get out on Sat at the earliest. Thanks 
for making those changes - I'm sure they will help a lot for interactive 
use and animations.
-Jeff

Jeff Whitaker wrote:
> Eric Firing wrote:
>> Jeff,
>>
>> Basemap methods like plot() include a "draw_if_interactive" command, 
>> followed by a call to the set_axes_limits() method, which ends with
>>
>> # force draw if in interactive mode.
>> if is_interactive():
>> figManager = _pylab_helpers.Gcf.get_active()
>> figManager.canvas.draw()
>>
>> It seems to me that you could eliminate all those 
>> "draw_if_interactive" blocks from plot etc., and replace the end block 
>> of set_axes_limits() with
>>
>> if is_interactive():
>> import matplotlib.pyplot as plt
>> plt.draw_if_interactive()
>>
>> The advantages would be reduced clutter in the drawing methods, and 
>> consistent use of draw_if_interactive. I think the latter would make 
>> interactive running of functions and subclasses built on basemap more 
>> efficient by reducing redundant draw operations.
>>
>> It also looks like at least most of the operations in set_axes_limits 
>> really need to be done only once (although I have not checked this 
>> carefully). Instead of repeating them with every call to a plotting 
>> method, the basemap instance could keep a list of hashes of axes 
>> objects on which the operations have already been run, and use that to 
>> prevent duplication.
>>
>> Nothing urgent here--just some ideas that occur to me while working 
>> with basemap. If you think any are worth pursuing, and you want me to 
>> take a shot at it, let me know.
>>
>> Eric
>>
>>
>> 
> Eric: You are right, that could be done much more efficiently. I'm 
> stuck in the U.K. waiting for the volcanic dust to clear, so if you want 
> to take a shot at it go ahead.
> 
> -Jeff
> 
Jeff,
I made the changes, and removed a few obsolete bits.
I hope you are cleared to fly soon, if you have not already departed.
Eric

Jae-Joon Lee wrote:
> Eric,
> 
> Just a minor concern about "locator_params" implicitly calling "autoscale_view".
> For example,
> 
> ax1 = subplot(121)
> ax1.plot([1,2,3])
> ax1.locator_params("x", nbins=5)
> ax1.margins(0.1, tight=True)
> 
> ax2 = subplot(122)
> ax2.plot([1,2,3])
> ax2.margins(0.1, tight=True)
> ax2.locator_params("x", nbins=5)
> 
> Same commands are applied to each subplot but with different order,
> and the results are different.
> "ax.2locator_params("x", bnins=5)" implicitly calls
> "ax2.autoscale_view(tight=False)", overriding tight=True in margins
> call.
> 
> And I think this is a bit confusing.
I agree, and I was aware of this problem. It arises from the fact that 
the "tight" state is not saved, as I think it should be. I will look 
into fixing that.
> 
> I understand that autoscale_view depends on locator. Still at least
> some option to prevent calling "autoscale_view" may be needed?
That seems to me like a more complex and confusing solution than saving 
the "tight" setting, and keeping it until it is explicitly changed by 
its own setter, by autoscale_view, or by margins. The default for 
autoscale_view will then be to change "tight" only if the kwarg is 
provided and is not None.
Eric
> 
> Regards,
> 
> -JJ

Eric,
Just a minor concern about "locator_params" implicitly calling "autoscale_view".
For example,
ax1 = subplot(121)
ax1.plot([1,2,3])
ax1.locator_params("x", nbins=5)
ax1.margins(0.1, tight=True)
ax2 = subplot(122)
ax2.plot([1,2,3])
ax2.margins(0.1, tight=True)
ax2.locator_params("x", nbins=5)
Same commands are applied to each subplot but with different order,
and the results are different.
"ax.2locator_params("x", bnins=5)" implicitly calls
"ax2.autoscale_view(tight=False)", overriding tight=True in margins
call.
And I think this is a bit confusing.
I understand that autoscale_view depends on locator. Still at least
some option to prevent calling "autoscale_view" may be needed?
Regards,
-JJ

On Tue, Apr 20, 2010 at 4:02 PM, John Hunter <jd...@gm...> wrote:
> On Tue, Apr 20, 2010 at 3:26 PM, Ryan May <rm...@gm...> wrote:
>> Hi,
>>
>> Continuing the spurt of (independent) development that's been going on
>> lately, I committed support for generic timers. There's a base class
>> TimerBase that provides the basic API for a timer (start, stop,
>> controlling the interval, adding callbacks, etc.), and each GUI
>> backend subclasses this to wrap around their toolkit's native timer
>> classes. I added a method to each backend's canvas object to
>> facilitate creating a backend-specific timer without having to know
>> what backend was running. So far, I'm quite happy with how it turned
>> out, but I'm curious to hear feedback. Specifically:
>>
>> 1) Anything missing in the basic TimerBase API?
>
> You might want to pass the argument as keywords on from the
> add_timerr, so you can do
>
> timer = fig.canvas.new_timer(interval=100, callbacks=[(update_title, ax)])
>
> or something like that... Or support a single callback object.
I'll look at that. I had been trying to keep the constructor simple,
but those extra calls to get it fully initialized aren't in line with
the rest of the matplotlib API (been doing too much Qt!). I'll
probably make it callbacks=[(func, args, kwargs)], as I think I'm
going to go back and add **kwargs anyways.
> Speaking of callbacks, do you know about cbook.CallbackRegistry? It
> would be nice to standardize on a single interface for handling
> callbacks so users and developers can manipulate it directly.  We use
> this elsewhere in support of mpl event handling and the toolbar so it
> is fairly robust.
Can you further describe what you see here? I looked at this before,
and it seems more valuable if you have a variety of signals. I would
have 1. I *could* add a time_event to the list of events in the
canvas and use the canvas-level callback registry, but that would
actually seem to undo the encapsulation of the timer object. Plus
that would only allow one timer attached to a canvas. More
importantly, the CallbackRegistry, when processing signals, calls each
callback with the same arguments, so there's no way to specify per
callback information. Maybe I'm just being dense, so please correct
me if I'm missing your vision here. I'd always love to reuse existing
code and reduce my "opportunity" to contribute bugs to matplotlib. :)
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Apr 20, 2010 at 3:26 PM, Ryan May <rm...@gm...> wrote:
> Hi,
>
> Continuing the spurt of (independent) development that's been going on
> lately, I committed support for generic timers. There's a base class
> TimerBase that provides the basic API for a timer (start, stop,
> controlling the interval, adding callbacks, etc.), and each GUI
> backend subclasses this to wrap around their toolkit's native timer
> classes. I added a method to each backend's canvas object to
> facilitate creating a backend-specific timer without having to know
> what backend was running. So far, I'm quite happy with how it turned
> out, but I'm curious to hear feedback. Specifically:
>
> 1) Anything missing in the basic TimerBase API?
You might want to pass the argument as keywords on from the
add_timerr, so you can do
 timer = fig.canvas.new_timer(interval=100, callbacks=[(update_title, ax)])
or something like that... Or support a single callback object.
Speaking of callbacks, do you know about cbook.CallbackRegistry? It
would be nice to standardize on a single interface for handling
callbacks so users and developers can manipulate it directly. We use
this elsewhere in support of mpl event handling and the toolbar so it
is fairly robust.
> 2) Is adding new_timer() the canvas a good way to go? I needed a way
> to get to backend-specific classes without actually knowing what
> backend I'm running (and without calling _pylab_helpers or
> pyplot.get_backend()). Figure.canvas seemed to be just about the only
> way to go about this. It also makes some sense, because in the case
> of Wx and Tk, an actual widget is required to hook up the timer.
>
> I've added an example in:
> examples/event_handling/timers.py
>
> This just makes a plot with a title that is continually (100 ms)
> updating with the current time including milliseconds. It does a good
> job of showing the ease with which such interactive updates can be
> done now. In fact, this could probably be used to update and simplify
> the existing animation demos. However, I'm already finishing up a more
> complete animation framework based on this, which should simplify some
> of those even further. At that point, I'll probably update the
> examples.
>
Looking forward to seeing it -- thanks!
JDH

Hi,
Continuing the spurt of (independent) development that's been going on
lately, I committed support for generic timers. There's a base class
TimerBase that provides the basic API for a timer (start, stop,
controlling the interval, adding callbacks, etc.), and each GUI
backend subclasses this to wrap around their toolkit's native timer
classes. I added a method to each backend's canvas object to
facilitate creating a backend-specific timer without having to know
what backend was running. So far, I'm quite happy with how it turned
out, but I'm curious to hear feedback. Specifically:
1) Anything missing in the basic TimerBase API?
2) Is adding new_timer() the canvas a good way to go? I needed a way
to get to backend-specific classes without actually knowing what
backend I'm running (and without calling _pylab_helpers or
pyplot.get_backend()). Figure.canvas seemed to be just about the only
way to go about this. It also makes some sense, because in the case
of Wx and Tk, an actual widget is required to hook up the timer.
I've added an example in:
examples/event_handling/timers.py
This just makes a plot with a title that is continually (100 ms)
updating with the current time including milliseconds. It does a good
job of showing the ease with which such interactive updates can be
done now. In fact, this could probably be used to update and simplify
the existing animation demos. However, I'm already finishing up a more
complete animation framework based on this, which should simplify some
of those even further. At that point, I'll probably update the
examples.
I still need to add some documentation to the event handling section
of the User's Guide, though this might better belong with a section on
animation's that I promise to write once the new framework is checked
in.
Also, I didn't add a TimerBase implementation for the CocoaAgg
backend. I have no idea about that toolkit, so I'd appreciate some
help there so we can have an implementation for all of the active GUI
toolkits.
Any feedback is appreciated.
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

On Tue, Apr 20, 2010 at 2:46 PM, Eric Firing <ef...@ha...> wrote:
> During the last few days I have added some convenience methods and
> pyplot functions. Please review them to see whether names, APIs, or
> functionality should be changed. The general motivation is that
> formatters and locators are a bit obscure and hidden in the object
> hierarchy, so I wanted to make it easier for people to make simple
> changes. In addition, in autoscaling, one might want an option that is
> almost "tight" but leaves a little margin, so symbols at the edge don't
> get sliced off, for example.
No comments other than these seem like really good changes to reduce
the barrier for the users.
Nice work!
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

During the last few days I have added some convenience methods and 
pyplot functions. Please review them to see whether names, APIs, or 
functionality should be changed. The general motivation is that 
formatters and locators are a bit obscure and hidden in the object 
hierarchy, so I wanted to make it easier for people to make simple 
changes. In addition, in autoscaling, one might want an option that is 
almost "tight" but leaves a little margin, so symbols at the edge don't 
get sliced off, for example.
At the Axes and pyplot levels, the changes made so far include expanding 
ticklabel_format() and adding two new methods/functions, 
locator_params() and margins(). The change to ticklabel_format is the 
addition of a new kwarg:
 *useOffset* [True | False | offset]; if True,
 the offset will be calculated as needed;
 if False, no offset will be used; if a
 numeric offset is specified, it will be
 used.
This involved changing the underlying ScalarFormatter to accept a 
numeric offset as an alternative to calculating it automatically.
The docstrings for the new methods are:
 def locator_params(self, axis='both', tight=False, **kwargs):
 """
 Convenience method for controlling tick locators.
 Keyword arguments:
 *axis*
 ['x' | 'y' | 'both'] Axis on which to operate;
 default is 'both'.
 *tight*
 [True | False] Parameter passed to :meth:`autoscale_view`.
 Remaining keyword arguments are passed to directly to the
 :meth:`~matplotlib.ticker.MaxNLocator.set_params` method.
 Typically one might want to reduce the maximum number
 of ticks and use tight bounds when plotting small
 subplots, for example::
 ax.locator_params(tight=True, nbins=4)
 Because the locator is involved in autoscaling,
 :meth:`autoscale_view` is called automatically after
 the parameters are changed.
 This presently works only for the
 :class:`~matplotlib.ticker.MaxNLocator` used
 by default on linear axes, but it may be generalized.
 """
and
 def margins(self, *args, **kw):
 """
 Convenience method to set or retrieve autoscaling margins.
 signatures::
 margins()
 returns xmargin, ymargin
 ::
 margins(margin, tight=True)
 margins(xmargin, ymargin, tight=True)
 margins(x=xmargin, y=ymargin, tight=True)
 All three forms above set the xmargin and ymargin parameters.
 All keyword parameters are optional. A single argument
 specifies both xmargin and ymargin. The *tight* parameter
 is passed to :meth:`autoscale_view`, which is executed after
 a margin is changed.
 Specifying any margin changes only the autoscaling; for example,
 if *xmargin* is not zero, then *xmargin* times the X data
 interval will be added to each end of that interval before
 it is used in autoscaling.
 """
Eric