matplotlib-users Mailing List for matplotlib

Hi,

I am writting an application in which I update dynamically the state  
of the figures. When I am done I call the Figure.canvas.draw function  
to redraw the figure. However, when the window was previously closed  
by the user the update can be skipped.

Is there a way to tell from a figure handle if the figure is shown on  
screen or not?

Currently, I solve this problem with a callback which sets the figure  
handle to None on figure close event. However, I guess there might be  
a more direct way of doing that. What would you suggest?

Thanks a lot for your help.

Bartosz

I don't know of a colormap like that, but you can build one pretty
easily by just finding the hex codes for the colors you want, and then
doing this:


mycm = matplotlib.colors.LinearSegmentedColormap.from_list("my_new_colormap",["#58c5cc","#5cc0a4","#34842f","#b3de1d"])
matplotlib.cm.register_cmap("my_new_colormap",cmap=mycm)


On Sat, Feb 12, 2011 at 10:02 AM, Alan G Isaac <ai...@am...> wrote:
> Can anyone share a colormap that goes from bright yellow to
> dark blue via green, along the lines of the middle 2/3 of
> gist_rainbow?
> http://www.scipy.org/Cookbook/Matplotlib/Show_colormaps
>
> Thanks,
> Alan Isaac
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
>



-- 
Daniel Hyams
dh...@gm...

Ben,

Thanks for the suggestions. I've updated the code accordingly. I tend to 
use **kwargs because it enforces passing arguments in by keyword, but 
your point on IDE friendliness is well taken. Someday, we'll move to 
Python 3 with its support for keyword-only arguments...

I've also added a license block releasing the code under the MIT 
license. If there's a reason it should be released under a different 
license as well, let me know.

Ray

On 2/12/2011 1:01 PM, Benjamin Root wrote:
>
>
> On Fri, Feb 11, 2011 at 3:06 PM, Ray Speth <sp...@mi...
> <mailto:sp...@mi...>> wrote:
>
>     Hi,
>
>     I wrote a script to generate streamline plots using matplotlib a while
>     ago, and this post inspired me to finally clean it up a bit. The code is
>     available at http://web.mit.edu/speth/Public/streamlines.py and you can
>     see an example of its output at
>     http://web.mit.edu/speth/Public/streamlines.png
>
>     I'd be happy to have it find a home in matplotlib if it would be useful
>     to other people there.
>
>     Ray
>
>
> Ray,
>
> That is absolutely beautiful work there.
>
> At the very least, I would like to see this added to the gallery or the
> cookbook.  The code is very nicely commented and documented.  Just a few
> points that come to mind.
>
> First, consider the possibility of using asanyarray() instead of
> asarray().  The big usecase for asanyarray is the use of masked arrays.
>
> Second, I am personally against call signatures that are just "**kwargs"
> and then popping off the arguments at the beginning of the method.  So
> long as the default value is not a mutable object, then put those
> arguments in the call signature with the default values.  It is much
> more IDE and documentation-friendly this way.
>
> Third, I would think that using plt.gca() would be better than
> plt.axes() just in case the user is using subplots.  gca() will create
> an axes if none exists already.
>
> Lastly, you should do ax.plot() instead of plt.plot() since you have
> already retrieved the axes object.  This way, in case the axes object
> passed in is not the currently active axes, it would still work.
>
> The difficulty in getting this included into matplotlib proper (and the
> same goes to the other thread about streamgraphs) is that these plots
> are done in an object oriented rather than procedural approach.
> Personally, I would like to see (one day) a refactor of matplotlib where
> everything plotable is an object that gets placed into the axes object
> (which, itself is a plotable that gets placed in a figure...).  While
> the current code isn't too far from that concept, the interface is
> ultimately procedural.
>
> @everyone else:
> The big reason I see for a future refactor to an object-oriented
> approach is that plots are getting more complicated, and we can't just
> keep on adding more methods to the axes object.  A more object-oriented
> approach would allow for complex graphs to be placed into their own
> modules, and yet still be treated the same as any other plotting
> method.  It would also make it easier for others to extend matplotlib's
> plotting features.
>
> Ben Root
>