matplotlib-users Mailing List for matplotlib (Page 2)

Hi folks,
this might be a trivial question, but I could not figure it out from the
documentation or the examples.
I have a plot where the x-scale ranges from 0 to 20.
When I plot a line it automatically starts at x=0. I would like the line to
start at x=1. Is there a way to how I can do that?
Any help appreciated
regards
Oliver

> You do have the option of using a GUI native drawing backend, eg GTK
> instead of GTKAgg or WX instead of WXAgg. Because we use double
> buffering in GTK, it may not help (Steve -- would it be possible to
> make double buffering optional?) The native GTK drawing is inferior
> to Agg, in my view, but you may be willing to trade quality for
> speed. 
I've added a 'DBL_BUFFER' variable to backend_gtk.py to switch on/off
double buffering for the GTK backend.
Switching off double buffering makes widget redraws flicker (as you'd
expect). I can't see how disabling double buffering has any value, or
how it could be useful when running python remotely, perhaps I'm wrong -
feel free to test it and let me know if it does have a use.
Steve

Having some email problems, my original reply wasnt sent. Hopefully this one 
will be...
On Thursday 24 February 2005 11:02 pm, John Hunter wrote:
> >>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:
>
> Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show()
>
> Hans> All works fine when I subtract the mean of x but there seems
> Hans> to be a problem with labelling axes for plotted data which
> Hans> is not close to zero but shows only small variations.
>
> I agree it's a bug. It's not immediately clear to me what the labels
> should be though
>
> 1.0000000002
> 1.0000000004
> 1.0000000006
>
> and so on? That takes up a lot of room. Granted, correct but ugly
> is better than incorrect but pretty, but I'm curious if there is a
> better way to format these cases. Perhaps ideal would be an indicator
> at the bottom or top of the y axis that read '1+' and then use 2e-9,
> 4e-9, etc as the actual tick labels. Do you agree this is ideal?
Matlab will not do an offset of this type, it goes to 4 decimal places and 
gives up. I have been meaning to do some work with the scalarFormatter for a 
while now. I think we can accomplish the above using the numerix mean,std,and 
maybe allclose functions. I will work on it this weekend, but will need some 
guidance to add a new bbox to add the result to the plot. At the same time, 
I'll work on an option to move the scientific notation to the same place, so 
1e10,2e10 will be come 1,2, with a x10^10 at the top of the axis.
It was also suggested to keep the significant decimal points in the labels. I 
agree with that 0,0.5,1.0,1.5 looks better than 0,0.5,1,1.5. If there are any 
suggestions or comments, please let me know.
-- 
Darren

On Wednesday 23 February 2005 12:06 pm, Darren Dale wrote:
> On Wednesday 23 February 2005 10:51 am, John Hunter wrote:
> > >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> >
> > Darren> backend_qt.py is present in my cvs directory, but it looks
> > Darren> like it didnt make it into the MPL-0.72 tarball.
> >
> > This was a problem with the MANIFEST file in the 0.72 release. I
> > should be fixed in the 0.72.1 bugfix release, which is up on the sf
> > site.
>
> Great! One bug to report. Line 262 of backend_qt.py should read:
>
> error_msg = error_msg_qt
>
> or I get an error:
>
> File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py",
> line 262, in ?
> error_msg = error_msg
> NameError: name 'error_msg' is not defined
I see my comments above do not apply to the version in cvs, due to changes in
error handling. In cvs, line 279 should be
if len( msg ) : error_msg_qt( msg )
Darren
-------------------------------------------------------
-- 
Darren

Hi John,
> Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show()
>
> Hans> All works fine when I subtract the mean of x but there seems
> Hans> to be a problem with labelling axes for plotted data which
> Hans> is not close to zero but shows only small variations.
>
> I agree it's a bug. It's not immediately clear to me what the labels
> should be though
>
> 1.0000000002
> 1.0000000004
> 1.0000000006
>
> and so on? That takes up a lot of room. Granted, correct but ugly
> is better than incorrect but pretty, but I'm curious if there is a
> better way to format these cases. Perhaps ideal would be an indicator
> at the bottom or top of the y axis that read '1+' and then use 2e-9,
> 4e-9, etc as the actual tick labels. Do you agree this is ideal?
That would be very cool ;-) [but not soo easy to code I suppose]. I just 
checked what Matlab does (seeing that they have been in the business for a 
while), and if I run the equivalent program (i.e. plotting date from 
1+0e-9, 1+1e-9, 1+2e-9,...,1e-8), the plot just shows "1" at each tick.
So: yes, I agree with your suggested ideal solution but as long as Matlab 
doesn't do this and there is a workaround (as you show below), this is 
probably not a high-priority bug ;-)
> To achieve this, as you may know, you can pass in a custom tick
> formatter. Eg
>
> import pylab
>
> def myformatter(x, pos):
> return '%1.0e'%(x-1)
>
> ax = pylab.subplot(111)
> x=pylab.arange(0,1e-8,1e-9)+1.0
> ax.plot(x)
> formatter = pylab.FuncFormatter(myformatter)
> ax.yaxis.set_major_formatter(formatter)
> ax.text(-.125, 1.025, '1+', transform=ax.transAxes)
> pylab.show()
>
> See also examples/custom_ticker1.py.
>
> This is not to say that I don't want to fix this bug; I just wanted to
> make sure you are aware of this workaround.
That's very useful information -- I wasn't aware of this possibility and 
am sure it will be useful to others searching the mailing list for 
answers.
Best wishes,
Hans

>>>>> "Yann" == Yann Le Du <yan...@no...> writes:
 Yann> Hello, Is there a simple argument to pass to matshow so that
 Yann> it'll print 0 as white and 1 as black, and not the opposite
 Yann> as it defaults to ?
You can do this by passing a custom colormap to the matshow function.
See the following threads on the mailing list archive for more
information on creating custom colormaps
 http://sourceforge.net/mailarchive/message.php?msg_id=10482430
 http://sourceforge.net/mailarchive/message.php?msg_id=10020116
See also the user's guide section 6.4.4 "Defining your own colormap"
You might also want to spend a little time looking at the src code of
the matplotlib modules cm and colors for inspiration on how to define
your own. 
Hopefully we can improve the documentation and example code in this
area in the not too distant future...
Hope this helps,
JDH

>>>>> "Humufr" == Humufr <hu...@ya...> writes:
 Humufr> the marker 'x' (ex: plot(a,b,'bx',markersize=5) are not
 Humufr> working anymore (at least version 0.72.1 and cvs) with Agg
 Humufr> backend (and TkAgg and GTKAgg). With PS backend it's ok.
OK, thanks for letting me know. This will be fixed in the next bugfix
release of mpl.
JDH

>>>>> "Hans" == Hans Fangohr <H.F...@so...> writes:
 
 Hans> x=pylab.arange(0,1e-8,1e-9)+1.0 pylab.plot(x) pylab.show()
 Hans> All works fine when I subtract the mean of x but there seems
 Hans> to be a problem with labelling axes for plotted data which
 Hans> is not close to zero but shows only small variations.
I agree it's a bug. It's not immediately clear to me what the labels
should be though
 1.0000000002
 1.0000000004
 1.0000000006
and so on? That takes up a lot of room. Granted, correct but ugly
is better than incorrect but pretty, but I'm curious if there is a
better way to format these cases. Perhaps ideal would be an indicator
at the bottom or top of the y axis that read '1+' and then use 2e-9,
4e-9, etc as the actual tick labels. Do you agree this is ideal?
To achieve this, as you may know, you can pass in a custom tick
formatter. Eg
 import pylab
 def myformatter(x, pos):
 return '%1.0e'%(x-1)
 ax = pylab.subplot(111)
 x=pylab.arange(0,1e-8,1e-9)+1.0
 ax.plot(x)
 formatter = pylab.FuncFormatter(myformatter)
 ax.yaxis.set_major_formatter(formatter)
 ax.text(-.125, 1.025, '1+', transform=ax.transAxes)
 pylab.show()
See also examples/custom_ticker1.py.
This is not to say that I don't want to fix this bug; I just wanted to
make sure you are aware of this workaround. 
JDH

the marker 'x' (ex: plot(a,b,'bx',markersize=5) are not working anymore 
(at least version 0.72.1 and cvs) with Agg backend and derived (TkAgg 
and GTKAgg). With PS or PNG backends it's ok.
The error message is:
Traceback (most recent call last):
 File "/usr/local/lib/python2.4/lib-tk/Tkinter.py", line 1345, in __call__
 return self.func(*args)
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py", 
line 140, in resize
 self.show()
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py", 
line 143, in draw
 FigureCanvasAgg.draw(self)
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
line 319, in draw
 self.figure.draw(self.renderer)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/figure.py", 
line 338, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/axes.py", line 
1296, in draw
 a.draw(renderer)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/lines.py", line 
294, in draw
 markerFunc(renderer, gc, xt, yt)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/lines.py", line 
1044, in _draw_x
 renderer.draw_line(gc, x-offset, y-offset, x+offset, y+offset)
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
line 155, in draw_line
 self._renderer.draw_lines(gc, x, y)
IndexError: Unexpected SeqBase<T> length.
thanks.

Hi all,
I'm an absolutely matplotlib newbie, so I'm sorry if my question is 
trivial. Anyway I've read the user guide and looked at the examples 
without finding out a solution.
Here it is my problem. Suppose I have a 2-dimensional array containg my 
data, and I want to produce a surface or a contour plot with it. Now 
the imshow() function seems the right way to go through. So far so 
good. Now suppose I want to draw the x,y axes for this plot, and 
suppose my axes are represented by **not-uniform** 1-dimensional array 
x[i], y[j]. How can I get the right ticks on the plot axes??
I hope to have been clear. Thanks in advance,
 Andrea.

the marker 'x' (ex: plot(a,b,'bx',markersize=5) are not working anymore 
(at least version 0.72.1 and cvs) with Agg backend (and TkAgg and 
GTKAgg). With PS backend it's ok.
The error message is:
Traceback (most recent call last):
 File "/astro/homes/gruel/usr/local//lib/python2.4/lib-tk/Tkinter.py", 
line 1345, in __call__
 return self.func(*args)
 File 
"/astro/homes/gruel/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py", 
line 140, in resize
 self.show()
 File 
"/astro/homes/gruel/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_tkagg.py", 
line 143, in draw
 FigureCanvasAgg.draw(self)
 File 
"/astro/homes/gruel/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
line 319, in draw
 self.figure.draw(self.renderer)
 File 
"/astro/homes/gruel/usr/local/lib/python2.4/site-packages/matplotlib/figure.py", 
line 338, in draw
 for a in self.axes: a.draw(renderer)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/axes.py", line 
1296, in draw
 a.draw(renderer)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/lines.py", 
line 294, in draw
 markerFunc(renderer, gc, xt, yt)
 File "/usr/local/lib/python2.4/site-packages/matplotlib/lines.py", 
line 1044, in _draw_x
 renderer.draw_line(gc, x-offset, y-offset, x+offset, y+offset)
 File 
"/usr/local/lib/python2.4/site-packages/matplotlib/backends/backend_agg.py", 
line 155, in draw_line
 self._renderer.draw_lines(gc, x, y)
IndexError: Unexpected SeqBase<T> length.
thanks.

This is somewhat off topic, but: I've been trying to build matplotlib 
(and numarray and scipy for that matter) with 'python setup.py 
bdist_rpm'. This works fine on a Fedora Core 3 system. It does not 
work on FC1 with its default Python 2.2 installation, nor does it work 
if I install Python 2.3 from the FC1 RPMs at python.org and do 
'python2.3 setup.py bdist_rpm' on the FC1 system. The version of 
distutils on the FC3 system and the FC1 Python 2.3 install seems to be 
the same. Since the FC1 system is supposed to be a stable server, I'm 
loathe at the moment to risk updating it to FC3.
Any help?

>>>>> "Malte" == Malte Marquarding <Mal...@cs...> writes:
 Malte> John, When do you expect this to be implemented?
 Malte> I'd like to roll out a package depending on matplotlib and
 Malte> have a request for this specific feature.
I took a look at implementing this last week and talked with Fernando
Perez who did the matplotlib pylab support for ipython, we came to the
conclusion, that this needs to be done at the interactive shell
level. The basic problem is that although you are blocking, you need
to still share cpu time with the gui thread, so that you can continue
to interact with your plot and generate events. What shell and
backend are you using?
In the meantime, you might want to suggest this idiom to your user who
is asking for a blocking event
class Catcher:
 event = None
 def __call__(self, event):
 self.event = event
plot([1,2,3])
c = Catcher()
connect('button_press_event', c)
# no go click on the axes
print c.event.xdata, c.event.ydata
# and click somewhere else
print c.event.xdata, c.event.ydata
So even though the call is not blocking you have ready access to the
event data in as way that doesn't feel like event driven programming
with callbacks.
I like this approach, actually. I wonder if it would be useful to
assign some new pylab module variables
bp = Catcher()
connect('button_press_event', bp)
br = Catcher()
connect('button_release_event', br)
kp = Catcher()
connect(key_press_event', kp)
and so on. Then in the pylab interface, w/o making any connections
yourself, you would always have access to the last keypress event as
kp.event
and so on.
Do people think this would be useful for interactive work?
JDH

Hi Hans,
Let me ask, what do you think would be the correct labels? As I remember, 
Matlab will go out to 4 decimal points, so your ticks would be labeled 
1,1.0000,1.0000.
I have been meaning to do some work with the tick formatters. It has been 
suggested here that all significant digits are preserved, so for example, 
your ticks would be 1,1,1 (If you want to go out to 9 sig digits, I think you 
would have to write your own custom formatter, which is discussed on this 
list and in the user's guide). If you ticks are 1,1.01,1.02, the labels would 
be 1.00,1.01,1.02. I think this results in the best looking result, but I'd 
like to know others opinions before I start. Also, for ticks like 
1e5,2e5,3e5, I am intending to make the ticks 1,2,3, and have a x10^5 just 
outside the axis or in the last label. Comments, suggestions?
Darren
On Thursday 24 February 2005 05:53 am, Hans Fangohr wrote:
> Dear Matplotlib developers,
>
> running the following program
>
> import pylab
>
> x=pylab.arange(0,1e-8,1e-9)+1.0
> pylab.plot(x)
> pylab.show()
>
> with matplotlib 0.70.1 results in a graph that shows:
>
> (i) correctly the linear increase of x
> (ii) but the labels on the y-axis of the plot all show "1e", apart from
> the lowest one, which shows (correctly) just "1".
>
> All works fine when I subtract the mean of x but there seems to be a
> problem with labelling axes for plotted data which is not close to zero
> but shows only small variations.
>
> By the way: thank you for providing matplotlib.
>
> Cheers,
>
> Hans
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Matplotlib-users mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-users
-- 
Darren

Dear Matplotlib developers,
running the following program
import pylab
x=pylab.arange(0,1e-8,1e-9)+1.0
pylab.plot(x)
pylab.show()
with matplotlib 0.70.1 results in a graph that shows:
(i) correctly the linear increase of x
(ii) but the labels on the y-axis of the plot all show "1e", apart from 
the lowest one, which shows (correctly) just "1".
All works fine when I subtract the mean of x but there seems to be a 
problem with labelling axes for plotted data which is not close to zero 
but shows only small variations.
By the way: thank you for providing matplotlib.
Cheers,
Hans

Upfront disclaimer: like I said yesterday, I wrote those e-mails when
my frustration with a number of things completely boiled over. Then I
just core dumped everything that was bothering me into the mails.
Probably the only thing that's useful beyond the scope of the specific
problems I was experiencing are my comments about unused keyword
arguments. 
* Perry Greenfield <pe...@st...> wrote:
>>Gripe #3 is related to interactive windows when Python and the X11
>>server are connected by a slow link. 
> This is a consequence of how most of the interactive backends are 
> implemented. 
> ...
> Implementing the backends using their built in plotting commands 
> may be a way around this, but it means having much higher maintenance 
> costs for backends and lots of annoying capability mismatches (some 
> backends don't support rotated text, alpha blending, etc.)
I figured it was something like this, and I can understand that the
benefits of a common rendering engine outweigh the admittedly small
benefit of fast remote X11 redraws. Furthermore I've more or less
solved the problem for myself by using non-interactive backends with a
combination of scripts and ssh tunnels that watch for changes in a
file on the remote machine and, when it is modified, sends the file
over the link, where (similarly) a script is watching for changes in
the _local_ file and lauches a viewer. Not sure why this seems to
make a difference (all the pixel data is going over the channel in
either case) but it seems to make a big difference.
* John Hunter <jdh...@ni...> wrote:
> Greg> Gripe #2 is that it would be nice if the same word were
> Greg> abbreviated the same way everywhere. Ie, either cmap or cm,
> Greg> not both.
> I don't think I agree with you here. matplotlib.cm is a *module* and
> cm is a convenient reference to that module for pylab interactive
> users who want to save on keystrokes. I think it would lead to
> confusion and hard to find bugs if a module name and a kwarg were the
> same. 
Not sure why this is the case. I realize that they're different
entities in the language, but they both help you with the same task.
Context always (?) allows the Python interpreter to know the
difference, and the exceptions that are thrown by problems with each
are different. As a user, the thought that goes through my head when
I'm using either one is "Something related to colormaps" and there's
an extra cognitive load associated with remembering that "Modules
related to colormaps" requires cm while "Arguments related to
colormaps" requires cmap.
> I don't see this as a huge problem since a simple pcolor?
> in ipython would have shown you the correct kwarg. 
True, but we're aiming high here. If I didn't care about things like
this, I'd use Fortran or C because everyone else does and I certainly
wouldn't have taken an interest in Python. If you can just guess
without referring to documentation and have software do what you want,
I think that's a sign of an elegant interface: it has anticipated my
desires.
> And if mpl had raised an exception on seeing cm as a kwarg as you
> suggest in gripe#1, it wouldn't have been a problem for you.
Quite true! The extra cognitive load would still be there, but
addressing grip #1 effectively would make this into a very small
annoyance rather than something that can cause real frustration.
> So in the near future, we may have a GTK backend that uses native
> drawing and looks good too. In which case you may get speed over an
> X11 connection as well as nice looking plots.
This sounds great. :-)
> Greg> Not everyone uses matplotlib inside of scripts! Judging
> Greg> from the manual, this is the only approved way to use the
> Greg> library.
> If the manual gives a different impression, that is unintentional,
> and may result from selective reading.
> ...
> Basically, the claim that we only support a scripting interface is
> not true.
I didn't mean to imply that this was a policy decision, only that it
seems to be an assumption that's made often in the manual.
Specifically the thing that set me off was what I referred to here:
> Greg> Looking through the manual, I
> Greg> find that I can specify it on the command line, in
> Greg> .matplotlibrc, or via matplotlib.use('..'), but only "before
> Greg> you import matplotlib.pylab"
I couldn't figure out why matplotlib.use(...) didn't seem to be doing
anything, and then I found the bit about it only working before you
import matplotlib.pylab. This is where my frustration boiled over,
and I dashed off the e-mail. That probably wasn't a great idea
(writing while angry) but what can I say? All of this together set me
off.
> matplotlib development usually happens when a developer needs a
> feature or one or more users make a case that a feature is important
> -- you are officially the second person to request the ability to
> switch backends interactively, if memory serves.
I'm certainly open to the idea of contributing code, but at this point
I'm obviously not in a position to do so since I'm still learning my
way around. Also, I can see that interactively switching
backends will be a seldom used feature. My desire for it (and
excessive frustration when I failed to find it) were due to an unhappy
confluence of events.
> that. As you'll see in that thread, Fernando is looking into ways to
> include the backend switching functionality into ipython, eg so you
> can run a script with
>>> run -backend PS somefile.py
It's true that this is done from an interactive Python shell, but I
wouldn't call this switching backends interactively. In general my
.py files contain only function definitions. So I would envision
being able to do things like this:
>>> %run defs.py
>>> z = read_data()
>>> make_plot(z)
>>> switch_backend('PS')
>>> make_plot(z)
Now, please keep in mind my comments above: that once I use mpl a
little more and establish a regular pattern of use, I don't expect
to need this feature much, if at all. I'm just commenting on the
example you gave.
> But even w/o this ease of use, in the current matplotlib release the
> pylab switch_backend function exists. 
Cool, I'll certainly give it a shot.
Thanks,
Greg

>>>>> "Tim" == Tim Leslie <ti...@cs...> writes:
 Tim> I'm working with data sampled at 500Hz but as you would know
 Tim> we're more interested in the 0-50Hz range. Is the some way to
 Tim> get the specgram() function to only show up a particular
 Tim> frequency range rather than downsampling the data to a lower
 Tim> sampling rate? I'm currently plotting with
 Tim> specgram(data, Fs=500) colorbar() show()
Set the ylimits of the specgram axes to show only the frequency bad of
interest
 specgram(data, Fs=500)
 ylim(0, 40)
 colorbar()
 Tim> but I'm not too sure where to go from here to achieve my
 Tim> aims.
 Tim> Thanks in advance and for putting together an amazingly
 Tim> useful package.
Your welcome! You may want to check out my eegview package at
http://pbrain.sf.net. It's poorly documented and I don't have a lot
of time to support it currently, but there is already a lot there and
if you wanted to contribute some effort to that rather than starting
over, that would be great. We are in the process of trying to hire
someone to help with the development, maintenance and documentation of
that package, so I suspect it will see some activity in the not too
distant future.
JDH

Hi John (and others),
I'm working with EEG data and want to use a specgram similar to what you
have in the example at the bottom of 
http://matplotlib.sourceforge.net/screenshots.html
I'm working with data sampled at 500Hz but as you would know we're more
interested in the 0-50Hz range. Is the some way to get the specgram()
function to only show up a particular frequency range rather than
downsampling the data to a lower sampling rate? I'm currently plotting
with 
 specgram(data, Fs=500)
 colorbar()
 show()
but I'm not too sure where to go from here to achieve my aims.
Thanks in advance and for putting together an amazingly useful package.
Tim Leslie

John,
When do you expect this to be implemented?
I'd like to roll out a package depending on matplotlib and have a request for 
this specific feature.
Cheers,
Malte.

Hello,
Is there a simple argument to pass to matshow so that it'll print 0 as 
white and 1 as black, and not the opposite as it defaults to ?
--
Yann Le Du

Darren,
All of the error handling code was recently reworked by John to make all of 
the front ends be consistent. So, that line doesn't even exist in the CVS 
repository anymore. If you sync to the latest CVS then you should be fine.
You can find the instructions for CVS access here: 
http://sourceforge.net/cvs/?group_id=80706
Ted
At 09:06 AM 2/23/2005, Darren Dale wrote:
>On Wednesday 23 February 2005 10:51 am, John Hunter wrote:
> > >>>>> "Darren" == Darren Dale <dd...@co...> writes:
> >
> > Darren> backend_qt.py is present in my cvs directory, but it looks
> > Darren> like it didnt make it into the MPL-0.72 tarball.
> >
> > This was a problem with the MANIFEST file in the 0.72 release. I
> > should be fixed in the 0.72.1 bugfix release, which is up on the sf
> > site.
>
>Great! One bug to report. Line 262 of backend_qt.py should read:
>
>error_msg = error_msg_qt
>
>or I get an error:
>
>File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py",
>line 262, in ?
> error_msg = error_msg
>NameError: name 'error_msg' is not defined
>
>--
>
>Darren
>
>
>-------------------------------------------------------
>SF email is sponsored by - The IT Product Guide
>Read honest & candid reviews on hundreds of IT Products from real users.
>Discover which products truly live up to the hype. Start reading now.
>http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
>_______________________________________________
>Matplotlib-users mailing list
>Mat...@li...
>https://lists.sourceforge.net/lists/listinfo/matplotlib-users
Ted Drain Jet Propulsion Laboratory ted...@jp... 

>>>>> "Greg" == Greg Novak <no...@uc...> writes:
 Greg> This is gripe #1: weak typing only works when using
 Greg> undefined variables bites you on the nose. Otherwise we're
This is a good point -- Norbert submitted a patch addressing this a
couple of months ago but it broke python2.2 so we unrolled it. I've
added it to my list of things to do. It's tricky to get right, but
it's manageable and important.
 Greg> Gripe #2 is that it would be nice if the same word were
 Greg> abbreviated the same way everywhere. Ie, either cmap or cm,
 Greg> not both.
I don't think I agree with you here. matplotlib.cm is a *module* and
cm is a convenient reference to that module for pylab interactive
users who want to save on keystrokes. I think it would lead to
confusion and hard to find bugs if a module name and a kwarg were the
same. Now cm may not be the best module name, perhaps cmaps would be
better. I don't see this as a huge problem since a simple 
 >>> pcolor? 
in ipython would have shown you the correct kwarg. And if mpl had
raised an exception on seeing cm as a kwarg as you suggest in gripe#1,
it wouldn't have been a problem for you.
BTW, do you know you can interactively change the colormap for an
existing plot with the jet, gray, hot, et al commands
 >>> pcolor(rand(12,12)) # use your default colormap
 >>> hot() # colormap is now hot
 >>> summer() # colormap is now summer
 Greg> Gripe #3 is related to interactive windows when Python and
 Greg> the X11 server are connected by a slow link. All of the
 Greg> interactive backends I've used for matplotlib look great,
 Greg> but render very slowly in this situation b/c they're sending
 Greg> all the pixel data. Since most plots consist of a few
 Greg> lines, a bit of text, and a few dots, it'd be nice if the
 Greg> windows rendered quickly over slow connections. For
 Greg> example, Gnuplot runs very well in this configuration. I
 Greg> realize that this doesn't invovle matplotlib per se, I just
 Greg> wanted to throw it out there as a concern.
Perry already addressed this -- basically because we have so many
python GUIs it becomes a maintenance nightmare to add new features if
we use native drawing. Using agg to render to a bitmap which is then
transferred to a GUI canvas means we can add a feature in one place
and Tk, Wx, GTk, Fltk and QT users automagically get it with *no*
changes to the GUI backend. It comes with a cost, as you observed.
You do have the option of using a GUI native drawing backend, eg GTK
instead of GTKAgg or WX instead of WXAgg. Because we use double
buffering in GTK, it may not help (Steve -- would it be possible to
make double buffering optional?) The native GTK drawing is inferior
to Agg, in my view, but you may be willing to trade quality for
speed. 
There is hope for you, however, that you can have the best of both
worlds. Steve says that GTK is moving to a Cairo renderer for GTK
2.8, which does provide nice graphics. And it is a happy confluence
of circumstances that 1) matplotlib has a Cairo backend, 2) the GTK
maintainer (Steve Chaplin) is also the author of the Cairo and
GTKCairo backends and 3) Steve is very good about keeping the GTK*
stuff up to the latest developments in the gtk world. So in the near
future, we may have a GTK backend that uses native drawing and looks
good too. In which case you may get speed over an X11 connection as
well as nice looking plots.
 Greg> I apologize for the negative tone of this mail. Don't get
 Greg> me wrong--I use matplotlib and I like it b/c it's the best
 Greg> thing I've found. However, I just had one of those
 Greg> "GAAARGHGGHHHH!" moments and it's taking a little while to
 Greg> de-stress.
No problem. With all the fan mail we're getting around here, we're
starting to get a little soft :-). Some well placed criticism keeps
us on our toes.
Thanks,
JDH

>>>>> "Greg" == Greg Novak <no...@uc...> writes:
 Greg> Not everyone uses matplotlib inside of scripts! Judging
 Greg> from the manual, this is the only approved way to use the
 Greg> library.
Hmm. Not quite true. I hear there is a fellow in Boulder who
sometimes uses matplotlib interactively <wink>. If the manual gives a
different impression, that is unintentional, and may result from
selective reading. Did you read section 1.5 with subheading
"Interactive"? Eg,
 The recommended way to use matplotlib interactively from a shell is
 with ipython, which has an pylab mode that detects your matplotlib
 .matplotlibrc file and makes the right settings to run matplotlib
 with your GUI of choice in interactive mode using threading. gtk
 users will need to make sure that they have compiled gtk with
 threading for this to work. Using ipython in pylab mode is
 basically a nobrainer because it knows enough about matplotlib
 internals to make all the right settings for you internally.
Fernando and I have spent a lot of time and effort to make matplotlib
work seamlessly in interactive use. The issues are non-trivial
because you have to handle threading to keep the GUI from stealing the
show. Because threading is always involved when using most GUIs from
a python shell, we also provide an example in examples/interactive.py
which three mpl developers collaborated on to show people the
beginnings of how to roll their own custom interactive GTK shell.
I've also added a lot of short aliases for long keywords so you can
do, for example
 >>> plot([1,2,3], ls='--', c='red')
instead of
 >>> plot([1,2,3], linestyle='--', color='red')
Basically, the claim that we only support a scripting interface is not
true. If you have specific things to suggest to further improve
interactive use, or documentation suggestions, fire away.
 Greg> There seems to be no way to change the backend in the middle
 Greg> of an interactive session. Looking through the manual, I
 Greg> find that I can specify it on the command line, in
 Greg> .matplotlibrc, or via matplotlib.use('..'), but only "before
 Greg> you import matplotlib.pylab"
matplotlib development usually happens when a developer needs a
feature or one or more users make a case that a feature is important
-- you are officially the second person to request the ability to
switch backends interactively, if memory serves.
The first person was Fernando Perez, who has driven many of the
improvements in interactive use because he makes lots of suggestions
and contributes code. Recently on matplotlib-devel, we discussed the
importance of being able to switch backends interactively
http://sourceforge.net/mailarchive/message.php?msg_id=10724264 and I
provided a pylab_interface function switch_backend which does just
that. As you'll see in that thread, Fernando is looking into ways to
include the backend switching functionality into ipython, eg so you
can run a script with
 >>> run -backend PS somefile.py
But even w/o this ease of use, in the current matplotlib release the
pylab switch_backend function exists. It's not documented because we
are still exploring and testing it and it is experimental. But I
added a docstring this morning which I'll paste in here
def switch_backend(newbackend):
 """
 Swtich the default backend to newbackend. This feature is
 EXPERIMENTAL, and is only expected to work switching to an image
 backend. Eg, if you have a bunch of PS scripts that you want to
 run from an interactive ipython session, yuo may want to switch to
 the PS backend before running them to avoid having a bunch of GUI
 windows popup. If you try to interactively switch from one GUI
 backend to another, you will explode.
 Calling this command will close all open windows.
 """
 Greg> I would be extremely happy if there were a way to change
 Greg> backends midstream from an interactive shell (I use ipython,
 Greg> for example)
Good. You should be extremely happy then. As I suggested above, this
feature is lightly tested, so let us know what you find.
JDH

On Wednesday 23 February 2005 10:51 am, John Hunter wrote:
> >>>>> "Darren" == Darren Dale <dd...@co...> writes:
>
> Darren> backend_qt.py is present in my cvs directory, but it looks
> Darren> like it didnt make it into the MPL-0.72 tarball.
>
> This was a problem with the MANIFEST file in the 0.72 release. I
> should be fixed in the 0.72.1 bugfix release, which is up on the sf
> site.
Great! One bug to report. Line 262 of backend_qt.py should read:
error_msg = error_msg_qt
or I get an error:
File "/usr/lib/python2.3/site-packages/matplotlib/backends/backend_qt.py", 
line 262, in ?
 error_msg = error_msg
NameError: name 'error_msg' is not defined
-- 
Darren

>>>>> "Darren" == Darren Dale <dd...@co...> writes:
 Darren> backend_qt.py is present in my cvs directory, but it looks
 Darren> like it didnt make it into the MPL-0.72 tarball.
This was a problem with the MANIFEST file in the 0.72 release. I
should be fixed in the 0.72.1 bugfix release, which is up on the sf
site.
JDH