matplotlib-devel Mailing List for matplotlib

Actually, it seems that the following thread is also relevant to this 
issue : [matplotlib-devel] merging sympy plotting stuff with matplotlib 
<http://www.mail-archive.com/mat...@li.../msg02276.html>

Hi,
I was wondering if anyone had thought about finding homes for some of
the functions in mlab that are useful outside of matplotlib? I'm
specifically thinking of psd, which has no equivalent (to my knowledge)
in numpy/scipy.
Thanks,
Ryan
-- 
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma

Paul Kienzle wrote:
> On Thu, Jan 31, 2008 at 08:38:35AM +0100, Rob Hetland wrote:
>> I was just working with a student to do this. It is straightforward 
>> (using norms, as Eric suggests), but not short. I think it would be 
>> good to include wrappers for creating these norms to MPL.
>>
>> The advantage is then it works for everything: pcolor, scatter, etc.
> 
> Couldn't you also do this by providing a short colourmap instead of
> fiddling the norms?
Yes, but it is not as general a solution. The BoundaryNorm that I will 
add allows arbitrary color boundaries, just as the specification of 
levels in contourf does.
Eric
> 
> 	- Paul

I have to report two more issues (sorry I'm reporting, not squashing, I'm 
swamped at work.)
imshow(rand(100,100))
colorbar()
The horizontal alignment of the ticklabels is off, they are centered on the 
axis rather than being positioned to the right of it. Also, the image appears 
to be shifted in the axes, to the left and the top by one pixel.
Darren

On Thu, Jan 31, 2008 at 08:38:35AM +0100, Rob Hetland wrote:
> 
> I was just working with a student to do this. It is straightforward 
> (using norms, as Eric suggests), but not short. I think it would be 
> good to include wrappers for creating these norms to MPL.
> 
> The advantage is then it works for everything: pcolor, scatter, etc.
Couldn't you also do this by providing a short colourmap instead of
fiddling the norms?
	- Paul

On Thu, Jan 31, 2008 at 08:20:37AM -0600, John Hunter wrote:
> As you know, this has been a much requested feature,
I know. I have wanted it pretty badly.
> and the hard part is to get something working across backends, which it
> looks like you've done.
Looks like it works OK. I would appreciate heads up from people who know
GTK, as I am not too sure of possibly garbbling the mainloop with my
kludge. But I have tested it quit extensively and it seems to work.
> I suggest a minor reorganization. Get rid of ginput.py altogether,
> add the BlockingMouseInput code to either backend_bases.py or
> figure.py. Make a figure.Figure.ginput method, so folks can use it
> outside of pylab, and then add a ginput method to pyplot.py which is a
> thin wrapper to the Figure.ginput method.
Yup, this seems like a good solution.
> If this seems like a good organization to you, I'll wait for a new
> patch and then contribute that.
Give me a few days, but it will come.
Cheers,
Gaël

Eric Firing wrote:
> Jordan,
>
> This sounds useful, but I think it can be implemented without any new 
> plot type, simply by using a different sort of norm to do the 
> colormapping. I need to add this anyway, and I have a prototype. It 
> is very simple. I will get it in within the next few days, and then 
> you can see whether it meets your needs.
>
> Eric
I assume you mean to use pcolor for this kind of plot, but with the 
added ability to specify levels. This doesn't do what I want; I want 
the ability to make large contiguous contourf-style areas outlined with 
contour-style lines that follow the grid edges, not the hundreds of 
little squares that pcolor makes. But I agree that this may not be 
useful enough to warrant a new plot type. I'll just keep using my 
hacked add-on code and if anyone else wants this kind of functionality, 
you can direct them to me.
Jordan

Fixed in SVN r4910. It was a mistake when upgrading agg from 2.3 to 2.4.
Cheers,
Mike
Darren Dale wrote:
> I just wanted to report some artifacts that appear when I use imshow from the 
> trunk:
> 
> a=arange(10000)
> a.shape=(100,100)
> #ok:
> figure()
> imshow(a,interpolation='nearest')
> figure()
> imshow(a,interpolation='bilinear')
> #odd:
> figure()
> imshow(a,interpolation='bicubic')
> figure()
> imshow(a,interpolation='spline16')
> figure()
> imshow(a,interpolation='gaussian')
> 
> Darren
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I just wanted to report some artifacts that appear when I use imshow from the 
trunk:
a=arange(10000)
a.shape=(100,100)
#ok:
figure()
imshow(a,interpolation='nearest')
figure()
imshow(a,interpolation='bilinear')
#odd:
figure()
imshow(a,interpolation='bicubic')
figure()
imshow(a,interpolation='spline16')
figure()
imshow(a,interpolation='gaussian')
Darren

This should now be fixed in SVN r4909. The padding between the axes and 
the tick labels was not getting updated when the dpi changed. (That's 
why Rob's workaround worked, because it set the dpi "early enough").
There is still a known dpi bug with custom-shaped scatter plots, but I 
hope to tackle that next.
Cheers,
Mike
Rob Hetland wrote:
> I noticed this bug last week (and forgot to send it in until now.. I 
> know.. shame on me..).
> 
> Here is the workaround (responsible for my laziness):
> 
> figure(dpi=500)
> # make a figure
> savefig(dpi=500)
> 
> That is, as long as the figure and savefig dpi match, it looks 
> alright. Otherwise, the tick labels are off.
> 
> I'm using recent svn (trunk).
> 
> -Rob
> 
> On Jan 31, 2008, at 8:00 AM, Eric Firing wrote:
> 
>> In the course of answering a question by Alan Isaac, I saved some
>> figures at different dpi values and hit a bug with png output:
>>
>> imshow(rand(100,100))
>> gcf().savefig('f200.png', dpi=200)
>>
>> This results in tick labels that overlap the image, and it gets worse
>> with higher dpi. PS backend output is OK.
>>
>> This is with svn trunk.
>>
>> Eric
>>
>> ---------------------------------------------------------------------- 
>> ---
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
> 
> ----
> Rob Hetland, Associate Professor
> Dept. of Oceanography, Texas A&M University
> http://pong.tamu.edu/~rob
> phone: 979-458-0096, fax: 979-845-6331
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

On Jan 29, 2008 8:15 PM, Gael Varoquaux <gae...@no...> wrote:
> Ooops, I had forgotten to add the Wx backend. Here is a new patch.
>
> By the way, with the wx backend, there seems to be a simple mistake in
> the "show" method of the figure manager, to reproduce the traceback do
> (with a recent ipython):
Hey Gael -- this is really cool. As you know, this has been a much
requested feature, and the hard part is to get something working
across backends, which it looks like you've done.
I suggest a minor reorganization. Get rid of ginput.py altogether,
add the BlockingMouseInput code to either backend_bases.py or
figure.py. Make a figure.Figure.ginput method, so folks can use it
outside of pylab, and then add a ginput method to pyplot.py which is a
thin wrapper to the Figure.ginput method.
If this seems like a good organization to you, I'll wait for a new
patch and then contribute that.
Thanks!
JDH

I noticed this bug last week (and forgot to send it in until now.. I 
know.. shame on me..).
Here is the workaround (responsible for my laziness):
figure(dpi=500)
# make a figure
savefig(dpi=500)
That is, as long as the figure and savefig dpi match, it looks 
alright. Otherwise, the tick labels are off.
I'm using recent svn (trunk).
-Rob
On Jan 31, 2008, at 8:00 AM, Eric Firing wrote:
> In the course of answering a question by Alan Isaac, I saved some
> figures at different dpi values and hit a bug with png output:
>
> imshow(rand(100,100))
> gcf().savefig('f200.png', dpi=200)
>
> This results in tick labels that overlap the image, and it gets worse
> with higher dpi. PS backend output is OK.
>
> This is with svn trunk.
>
> Eric
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

I was just working with a student to do this. It is straightforward 
(using norms, as Eric suggests), but not short. I think it would be 
good to include wrappers for creating these norms to MPL.
The advantage is then it works for everything: pcolor, scatter, etc.
-Rob
On Jan 31, 2008, at 12:07 AM, Eric Firing wrote:
> Jordan,
>
> This sounds useful, but I think it can be implemented without any new
> plot type, simply by using a different sort of norm to do the
> colormapping. I need to add this anyway, and I have a prototype. 
> It is
> very simple. I will get it in within the next few days, and then you
> can see whether it meets your needs.
>
> Eric
>
> Jordan Dawe wrote:
>> So I have a (slightly) new plot type I would like to add to the
>> matplotlib codebase, and I'd like to ask A) if people would be
>> interested in the patch and B) what the best way to implement it 
>> would be.
>>
>> I am currently calling the plot type "pcontourf"--it's essentially a
>> pcolor, but instead of a continuous color spectra of value, it plots
>> discrete levels of data like contourf does. I find this kind of plot
>> useful for model output--it displays the model grid, and also 
>> emphasizes
>> data transitions, for example, between the negative and positive 
>> areas
>> of a plot, better than pcolor. Essentially it is just a contourf
>> wrapper that, instead of calling contourf with values at the 
>> 'center' of
>> a grid cell, calls contourf with points at the edges of the grid 
>> cell so
>> you end up with rectangular areas.
>>
>> If someone is actually interested in clean this up and put it into 
>> svn,
>> my next question is where in the codebase would be the best place 
>> to put
>> it so I can make a clean diff file? pyplot.py? I don't quite
>> understand how the matplotlib module hierarchy works.
>>
>> Jordan
>>
>>
>> --------------------------------------------------------------------- 
>> ----
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
>> _______________________________________________
>> Matplotlib-devel mailing list
>> Mat...@li...
>> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
> ---------------------------------------------------------------------- 
> ---
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
----
Rob Hetland, Associate Professor
Dept. of Oceanography, Texas A&M University
http://pong.tamu.edu/~rob
phone: 979-458-0096, fax: 979-845-6331

In the course of answering a question by Alan Isaac, I saved some 
figures at different dpi values and hit a bug with png output:
imshow(rand(100,100))
gcf().savefig('f200.png', dpi=200)
This results in tick labels that overlap the image, and it gets worse 
with higher dpi. PS backend output is OK.
This is with svn trunk.
Eric

Jordan,
This sounds useful, but I think it can be implemented without any new 
plot type, simply by using a different sort of norm to do the 
colormapping. I need to add this anyway, and I have a prototype. It is 
very simple. I will get it in within the next few days, and then you 
can see whether it meets your needs.
Eric
Jordan Dawe wrote:
> So I have a (slightly) new plot type I would like to add to the 
> matplotlib codebase, and I'd like to ask A) if people would be 
> interested in the patch and B) what the best way to implement it would be.
> 
> I am currently calling the plot type "pcontourf"--it's essentially a 
> pcolor, but instead of a continuous color spectra of value, it plots 
> discrete levels of data like contourf does. I find this kind of plot 
> useful for model output--it displays the model grid, and also emphasizes 
> data transitions, for example, between the negative and positive areas 
> of a plot, better than pcolor. Essentially it is just a contourf 
> wrapper that, instead of calling contourf with values at the 'center' of 
> a grid cell, calls contourf with points at the edges of the grid cell so 
> you end up with rectangular areas.
> 
> If someone is actually interested in clean this up and put it into svn, 
> my next question is where in the codebase would be the best place to put 
> it so I can make a clean diff file? pyplot.py? I don't quite 
> understand how the matplotlib module hierarchy works.
> 
> Jordan
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

Michael Droettboom skrev:
> For some reason, when axis() is called, the "emit" flag (which 
> determines whether to update all of the shared axes) was being set to 
> False by default. There may be a good reason for this that I'm not 
> aware of, but it seems reasonably harmless, and doesn't break the 
> existing shared_axis examples. I've fixed this on the branch and the 
> trunk, but I'm happy to revert if anyone says "stop, bad idea!!!"
> 
Works for me. Thanks!
/Jörgen

Michael Droettboom skrev:
> Ok. I'll change this in SVN.
> 
It works for me now as well.
/Jörgen

2008年1月29日, Neil Crighton <nei...@gm...>:
>
> I think it would be a shame to lose the current matplotlib 3d plotting
> functionality, even if it's not ideal. I've found it very useful for
> plotting small sets of data, and much more straightforward to use than
> Mayavi or other vtk-based 3d plotting packages.
>
> Having said that, I'm not volunteering to make the 3d modules work
> with the new transforms :-/
>
I second everything ;)
Matthieu
-- 
French PhD student
Website : http://matthieu-brucher.developpez.com/
Blogs : http://matt.eifelle.com and http://blog.developpez.com/?blog=92
LinkedIn : http://www.linkedin.com/in/matthieubrucher

Ooops, I had forgotten to add the Wx backend. Here is a new patch.
By the way, with the wx backend, there seems to be a simple mistake in
the "show" method of the figure manager, to reproduce the traceback do
(with a recent ipython):
ipython -wthread -pylab
In [1]: f = figure()
In [2]: f.show()
Cheers,
Gaël
On Wed, Jan 30, 2008 at 03:05:13AM +0100, Gael Varoquaux wrote:
> Hi all,
> A while ago (a year or so), I was looking for a ginput-like function with
> matplotlib. For those who don't know what I am talking about, it is a
> blocking call that can be used in a script to ask the user to enter
> coordinnate by clicking on the figure. This is incredibly handy, as it
> allows some simple user interaction without worrying about events loop
> and Co.
> At the time I gave up on that. I have made progress with GUI and event
> loops, and a recent post on the matplotlib-user list put me back to work
> on this (
> http://www.nabble.com/ginput-is-here%21-%28for-wx-anyway%29-to14960506.html
> ).
> I have a preliminary patch to add this feature to matplotlib that I
> attach. I add a method to the backend canvases, to be able to deal with
> event-loop-handling, and following Jack Gurkesaft I create my own a small
> event-loop to poll for events inside my function. This is a kludge, but it
> allows to block the function while still processing events. If you have
> better ideas.
> I have implemented the functionnality for all the interactive backends I
> could test (and thus not cocoa), but I am not too sure my gtk code is
> kosher, I wouldn't mind advice on this one.
> The code of ginput itself is currently in a seperate file
> (matplotlib.ginput, that you can run for a demo) because I wasn't too
> sure where to add it.
> This is a first version of the patch. I would like comments on it,
> especially where to add the code itself, and if the proposed additions to
> the backends look all right.
> Once I have comments, I plan to:
> * Make right click cancel an input
> * Allow infinite number of inputs, terminated by right-click
> * Add optional display of inputs
> * Rework docstrings
> More suggestions welcomed,
> This could (and should, IMHO) open the road to other blocking calls for
> user interaction, like the selection of a window, as they make life
> really easy for people wanting to hack quick data analysis scripts.
> Cheers,
> Gaël
> Index: trunk/matplotlib/lib/matplotlib/backend_bases.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/backend_bases.py	(revision 4908)
> +++ trunk/matplotlib/lib/matplotlib/backend_bases.py	(working copy)
> @@ -1151,7 +1151,13 @@
> """
> return self.callbacks.disconnect(cid)
> + def flush_events(self):
> + """ Flush the GUI events for the figure. Implemented only for
> + backends with GUIs.
> + """
> + raise NotImplementedError
> +
> class FigureManagerBase:
> """
> Helper class for matlab mode, wraps everything up into a neat bundle
> Index: trunk/matplotlib/lib/matplotlib/ginput.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/ginput.py	(revision 0)
> +++ trunk/matplotlib/lib/matplotlib/ginput.py	(revision 0)
> @@ -0,0 +1,80 @@
> +
> +from matplotlib.pyplot import gcf
> +import time
> +
> +class BlockingMouseInput(object):
> + """ Class that creates a callable object to retrieve mouse click 
> + in a blocking way, a la MatLab. 
> + """
> +
> + callback = None 
> + verbose = False
> +
> + def on_click(self, event):
> + """ Event handler that will be passed to the current figure to
> + retrieve clicks.
> + """
> + # if it's a valid click, append the coordinates to the list
> + if event.inaxes:
> + self.clicks.append((event.xdata, event.ydata))
> + if self.verbose: 
> + print "input %i: %f,%f" % (len(self.clicks), 
> + event.xdata, event.ydata)
> +
> + def __call__(self, fig, n=1, timeout=30, verbose=False):
> + """ Blocking call to retrieve n coordinate pairs through mouse 
> + clicks.
> + """
> +
> + assert isinstance(n, int), "Requires an integer argument"
> +
> + # Ensure that the current figure is shown 
> + fig.show()
> + # connect the click events to the on_click function call
> + self.callback = fig.canvas.mpl_connect('button_press_event', 
> + self.on_click)
> +
> + # initialize the list of click coordinates
> + self.clicks = []
> +
> + self.verbose = verbose
> +
> + # wait for n clicks
> + counter = 0
> + while len(self.clicks) < n:
> + fig.canvas.flush_events()
> + # rest for a moment
> + time.sleep(0.01)
> +
> + # check for a timeout
> + counter += 1
> + if timeout > 0 and counter > timeout/0.01: 
> + print "ginput timeout"; 
> + break;
> +
> + # All done! Disconnect the event and return what we have
> + fig.canvas.mpl_disconnect(self.callback)
> + self.callback = None
> + return self.clicks
> +
> +
> +def ginput(n=1, timeout=30, verbose=False):
> + """
> + Blocking call to interact with the figure. 
> +
> + This will wait for n clicks from the user and return a list of the 
> + coordinates of each click.
> +
> + If timeout is negative, does not timeout.
> + """
> +
> + blocking_mouse_input = BlockingMouseInput()
> + return blocking_mouse_input(gcf(), n, timeout, verbose=verbose)
> +
> +if __name__ == "__main__":
> + import pylab
> + t = pylab.arange(10)
> + pylab.plot(t, pylab.sin(t))
> + print "Please click"
> + ginput(3, verbose=True)
> +
> Index: trunk/matplotlib/lib/matplotlib/backends/backend_qt.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/backends/backend_qt.py	(revision 4908)
> +++ trunk/matplotlib/lib/matplotlib/backends/backend_qt.py	(working copy)
> @@ -175,6 +175,9 @@
> return key
> + def flush_events(self):
> + qt.qApp.processEvents()
> +
> class FigureManagerQT( FigureManagerBase ):
> """
> Public attributes
> Index: trunk/matplotlib/lib/matplotlib/backends/backend_gtk.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/backends/backend_gtk.py	(revision 4908)
> +++ trunk/matplotlib/lib/matplotlib/backends/backend_gtk.py	(working copy)
> @@ -386,6 +386,13 @@
> def get_default_filetype(self):
> return 'png'
> + def flush_events(self):
> + gtk.gdk.threads_enter() 
> + while gtk.events_pending():
> + gtk.main_iteration(True)
> + gtk.gdk.flush()
> + gtk.gdk.threads_leave()
> + 
> class FigureManagerGTK(FigureManagerBase):
> """
> Index: trunk/matplotlib/lib/matplotlib/backends/backend_tkagg.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/backends/backend_tkagg.py	(revision 4908)
> +++ trunk/matplotlib/lib/matplotlib/backends/backend_tkagg.py	(working copy)
> @@ -269,8 +269,9 @@
> key = self._get_key(event)
> FigureCanvasBase.key_release_event(self, key, guiEvent=event)
> + def flush_events(self):
> + self._master.update()
> -
> class FigureManagerTkAgg(FigureManagerBase):
> """
> Public attributes
> Index: trunk/matplotlib/lib/matplotlib/backends/backend_qt4.py
> ===================================================================
> --- trunk/matplotlib/lib/matplotlib/backends/backend_qt4.py	(revision 4908)
> +++ trunk/matplotlib/lib/matplotlib/backends/backend_qt4.py	(working copy)
> @@ -13,7 +13,7 @@
> from matplotlib.mathtext import MathTextParser
> from matplotlib.widgets import SubplotTool
> -from PyQt4 import QtCore, QtGui
> +from PyQt4 import QtCore, QtGui, Qt
> backend_version = "0.9.1"
> def fn_name(): return sys._getframe(1).f_code.co_name
> @@ -174,6 +174,9 @@
> return key
> + def flush_events(self):
> + Qt.qApp.processEvents()
> +
> class FigureManagerQT( FigureManagerBase ):
> """
> Public attributes
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
 Gael Varoquaux,
 Quantum degenerate gases group
 European Laboratory for Non-Linear Spectroscopy
 University of Florence, Polo Scientifico
 Via Nello Carrara 1, I-50019-Sesto-Fiorentino (Firenze) Italy
 Phone: ++ 390-55-457242145 Fax: ++ 390-55-4572451
 ++ and ++
 Groupe d'optique atomique,
 Laboratoire Charles Fabry de l'Institut d'Optique
 Campus Polytechnique, RD 128, 91127 Palaiseau cedex FRANCE
 Tel : 33 (0) 1 64 53 33 23 - Fax : 33 (0) 1 64 53 31 01
 Labs: 33 (0) 1 64 53 33 63 - 33 (0) 1 64 53 33 62

Hi all,
A while ago (a year or so), I was looking for a ginput-like function with
matplotlib. For those who don't know what I am talking about, it is a
blocking call that can be used in a script to ask the user to enter
coordinnate by clicking on the figure. This is incredibly handy, as it
allows some simple user interaction without worrying about events loop
and Co.
At the time I gave up on that. I have made progress with GUI and event
loops, and a recent post on the matplotlib-user list put me back to work
on this (
http://www.nabble.com/ginput-is-here%21-%28for-wx-anyway%29-to14960506.html
).
I have a preliminary patch to add this feature to matplotlib that I
attach. I add a method to the backend canvases, to be able to deal with
event-loop-handling, and following Jack Gurkesaft I create my own a small
event-loop to poll for events inside my function. This is a kludge, but it
allows to block the function while still processing events. If you have
better ideas.
I have implemented the functionnality for all the interactive backends I
could test (and thus not cocoa), but I am not too sure my gtk code is
kosher, I wouldn't mind advice on this one.
The code of ginput itself is currently in a seperate file
(matplotlib.ginput, that you can run for a demo) because I wasn't too
sure where to add it.
This is a first version of the patch. I would like comments on it,
especially where to add the code itself, and if the proposed additions to
the backends look all right.
Once I have comments, I plan to:
 * Make right click cancel an input
 * Allow infinite number of inputs, terminated by right-click
 * Add optional display of inputs
 * Rework docstrings
More suggestions welcomed,
This could (and should, IMHO) open the road to other blocking calls for
user interaction, like the selection of a window, as they make life
really easy for people wanting to hack quick data analysis scripts.
Cheers,
Gaël

Ok. I'll change this in SVN.
Nils Wagner wrote:
> On 2008年1月29日 15:33:46 -0500
> Michael Droettboom <md...@st...> wrote:
>> Ok, to save me the trouble of installing Python-2.4 (which doesn't 
>> feel like the culprit, but appears to be the only variable other than 
>> platform) I seem to recall a discussion on numpy about coercion of 
>> scalars to Python int's that may be the culprit here. Can you please 
>> add the following line above the line where the exception is raised in 
>> path.py, line 201, and then send me the output:
>>
>> print code, type(code), codes, type(codes)
>>
> 
> 1 <type 'numpy.uint8'> [1 2 1 2] <type 'numpy.ndarray'>
> 2 <type 'numpy.uint8'> [1 2 1 2] <type 'numpy.ndarray'>
> 1 <type 'numpy.uint8'> [1 2 1 2] <type 'numpy.ndarray'>
> 2 <type 'numpy.uint8'> [1 2 1 2] <type 'numpy.ndarray'>
> 
>> Also, does changing:
>>
>> num_vertices = NUM_VERTICES[code]
>>
>> to
>>
>> num_vertices = NUM_VERTICES[int(code)]
>>
>> resolve the problem?
> 
> Yes.
> 
> Cheers,
> Nils
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

I think it would be a shame to lose the current matplotlib 3d plotting
functionality, even if it's not ideal. I've found it very useful for
plotting small sets of data, and much more straightforward to use than
Mayavi or other vtk-based 3d plotting packages.
Having said that, I'm not volunteering to make the 3d modules work
with the new transforms :-/
Neil
>
> Message: 2
> Date: 2008年1月29日 15:07:31 -0500
> From: Michael Droettboom <md...@st...>
> Subject: Re:
> To: Johann Cohen-Tanugi <co...@sl...>, matplotlib
> development list <mat...@li...>
> Message-ID: <479...@st...>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Johann Cohen-Tanugi wrote:
> > is basemap deferred as well? It is kinda 3D no?
>
> I understand basemap is working reasonably well. But Jeff Whitaker
> would know better than I.
>
> > Second a color map or
> > contour plot is kinda 2D either...... unless I am confusing what you
> > mean by 2D : 2D in rendering or in data structure?
>
> I mean 2D in rendering -- matplotlib is fundamentally built on top of 2D
> rendering APIs, which makes doing a lot of 3D things more
> computationally expensive and less flexible than a dedicated 3D plotting
> package.
>
> > Anyway, I am probably not the motivated individual to tackle this work,
> > most of all because I do not know matplotlib internals, I am just a
> > user, albeit with coding abilities.
>
> Well, anyone can jump in ;) Unfortunately, I probably don't have the
> time for that now. I believe John Hunter has some more fully-formed
> ideas about where 3D in matplotlib should go and where the best path may
> be going forward.
>
> Cheers,
> Mike
>
> > Michael Droettboom wrote:
> >> Yes, it is probably a good-sized chunk of work. In the recent
> >> transforms overhaul, the 3d stuff was deferred, so it hasn't been
> >> updated to use the new "way of doing things".
> >>
> >> Just "getting it to work as it did before" is probably less work than
> >> "rethinking what 3D means in the context of matplotlib", which is a
> >> fundamentally 2D plotting environment. And there was some thinking
> >> along the lines of "why bother with the former, if the latter may be
> >> on the horizon?..." But I think it's going to take some motivated
> >> individual to step up and do either of these.
> >>
> >> Cheers,
> >> Mike
> >>

Ok, to save me the trouble of installing Python-2.4 (which doesn't feel 
like the culprit, but appears to be the only variable other than 
platform) I seem to recall a discussion on numpy about coercion of 
scalars to Python int's that may be the culprit here. Can you please 
add the following line above the line where the exception is raised in 
path.py, line 201, and then send me the output:
 print code, type(code), codes, type(codes)
Also, does changing:
 num_vertices = NUM_VERTICES[code]
to
 num_vertices = NUM_VERTICES[int(code)]
resolve the problem?
Cheers,
Mike
Jörgen Stenarson wrote:
> Michael Droettboom skrev:
>> Interesting. I can't reproduce this with Python-2.5 on Linux. What 
>> version of numpy do you have installed? Can you send your 
>> matplotlibrc file?
>>
> 
> I tried upgrading numpy to the latest svn version but I still see the 
> same problem. My matplotlibrc file is just the default created at 
> buildtime, I have attached it.
> 
> /Jörgen
> 
> 
> 
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA

Michael Droettboom skrev:
> Interesting. I can't reproduce this with Python-2.5 on Linux. What 
> version of numpy do you have installed? Can you send your matplotlibrc 
> file?
> 
I tried upgrading numpy to the latest svn version but I still see the 
same problem. My matplotlibrc file is just the default created at 
buildtime, I have attached it.
/Jörgen

For some reason, when axis() is called, the "emit" flag (which 
determines whether to update all of the shared axes) was being set to 
False by default. There may be a good reason for this that I'm not 
aware of, but it seems reasonably harmless, and doesn't break the 
existing shared_axis examples. I've fixed this on the branch and the 
trunk, but I'm happy to revert if anyone says "stop, bad idea!!!"
Cheers,
Mike
Jörgen Stenarson wrote:
> Hi,
> 
> I have problem setting the axis limits when using a twinx plot. I assume 
> it should be possible to set both x-axis limits after a pylab.twinx() 
> call by issuing only one call to pylab.axis.
> 
> The attached tries to plot the same figure in two different ways the 
> first way ends up with different x axis limits for the two plots. The 
> second shows my workaround.
> 
> /Jörgen
> 
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
-- 
Michael Droettboom
Science Software Branch
Operations and Engineering Division
Space Telescope Science Institute
Operated by AURA for NASA