matplotlib-devel Mailing List for matplotlib (Page 2)

John Hunter wrote:
> 
> ################ mathtext PS ################################
> 
> Fernando> mathtext support in the PostScript backend? I've read
> Fernando> your recent thread on the topic, but I wonder if you have
> Fernando> a timeline for this, and if there's any hope of it
> Fernando> happening sooner rather than later. I _loved_ the
> Fernando> mathtext plots, but unfortunately for academic use, proper
> Fernando> PostScript support is an inescapable necessity.
> 
> Paul, I told him you were working on this. Any progress?
Not lately. I'm currently on research leave and have a visitor from overseas 
for a few weeks, so haven't been able to find that spare moment to finish it up. 
 I realize that this is important, so I'll try to find sometime over the 
weekend to work on it. I was hoping to find some time last weekend. I know the 
basic steps that need to be done. I just need to understand the details. Sorry 
for the delay.
 -- Paul
-- 
Paul Barrett, PhD Space Telescope Science Institute
Phone: 410-338-4475 ESS/Science Software Branch
FAX: 410-338-4767 Baltimore, MD 21218

This is the second bugfix release of the 0.54 series
Here's the CHANGELOG
 * Rewrote ft2font using CXX as part of general memory leak fixes;
 also fixed transform memory leaks
 * Fixed several problems with log ticks and scaling 
 * Fixed width/height issues for images 
 * Fixed draw_if_interactive bug for semilogx; 
 * Fixed text clipping to clip to axes 
 * Fixed leading newline text and multiple newline text 
 * Fixed plot_date to return lines 
 * Fixed plot to work with x or y having shape N,1 or 1,N 
 * Added renderer markeredgewidth attribute of Line2D. 
 * Fixed tick label clipping to work with navigation.
 * Added renderer grouping commands to support groups in
 SVG/PS. 
 * Fixed, this time I really mean it, the singleton plot
 plot([0]) scaling bug; Fixed Flavio's shape = N,1 bug 
 * added colorbar 
 * Made some changes to the matplotlib.colors.Colormap to
 propertly support clim 
http://sourceforge.net/project/showfiles.php?group_id=80706&package_id=82474&release_id=244568

Jeremy,
> Not really. I am mostly interested in interactive usage, hence I
> am simply firing python or ipython from console, and then in
> python shell issuing couple of commands like:
>
> >>> from matplotlib.matlab import *
> >>> plot((1,2,3))
>
>
> You probably want.
>
> import matplotlib
> matplotlib.interactive(True)
> matplotlib.use('WX')
> from matplotlib.matlab import *
> plot([1,2,3])
What I forgot to mention is that I changed .matplotlibrc to use WX and 
interactive mode. In fact, all tests I did were performed the same way 
-- change .matplotlibrc to choose backend and set interactive to True or 
False, then open python from console try import/plot, open pythonwin try 
import/plot. I presume there is no difference between setting 
backend/interactivity via .matplotlibrc or via explicit calls to 
matplotlib api.
> There are a couple of issues I keep meaning to get around to fixing. 
> One problem is that I don't really use interactive mode, so I don't 
> notice things so much in that area (not that this is an excuse...). 
> The key difficulty is that the mainloop behaves subtly differently 
> when running interactively and from a script. Every time I make one 
> work correctly, it seems to break the other in unpredictable ways.
Yeah, quite a lot of different options to test, a lot of platforms, not 
to mention that testing GUI is hard by itself. World would be so much 
better if one could easily unittest GUIs.
>
> The -dWX option tells matplotlib to use the Wx renderer to run the 
> script. You can also set the preferred default renderer in the 
> matplotlibrc file. As installed, I think this defaults to GtkAgg, but 
> you can change it (see http://matplotlib.sourceforge.net/.matplotlibrc).
Oh, so that's yet another way to switch backends? Good to know.
> Boa is quite buggy in places, and imposes its own way of working with 
> Wx that doesn't suit me (at least for larger projects). However, the 
> debugger is worth the effort.
I see. I guess I have to find a combination of satisfactory IDE / 
matplotlib backend. From what I see now, Boa is pretty much the last 
resort for windows.
BTW, does anyone know what the situation is with various IDE / 
matplotlib backends compatibility on Linux? Particularly I am curious to 
know if there is a way to use matplotlib from Eric3, which is a QT based 
app.
> We've looked at different ways to deal with the mainloop problem, but 
> it is difficult to find a portable approach. It would probably be 
> quite straightforward to look at sys.argv and issue a different 
> matplotlib.use() call from there. Not sure that this would be easy to 
> generalise (as there are so many possible shells).
>
> In the longer term, John Hunter has been looking at putting the GUI 
> into a separate thread, to avoid mainloop problems. A partial solution 
> exists within scipy for this, but only applies, if memory serves, to 
> Wx only, whereas we would need a solution for all backends. We're 
> aware that this is quite annoying, although to be honest I think that 
> most people use only one backend with their preferred tools.
I see your point, the only reason I asked about automatic backend 
selection is because I may want to use matplotlib from different tools, 
say an IDE, xemacs, ipython, and it might be that they will require 
different backends, so I'll have to select one manually every time which 
is quite annoying. I guess we'll have to cope with it for now, hoping 
that one day you'll put GUI into a separate thread and it will resolve 
all issues.
BTW, how about plotting from separate process? Pickle data, send via 
some interprocess communication or even temporary file to plotting 
process. This should not be too hard to implement, right? It might be 
yet another backend.
--Kirill

On Tue, 2004年06月08日 at 16:47, John Hunter wrote:
> >>>>> "Jared" == Jared Wahlstrand <wah...@um...> writes:
> 
> Jared> Hello, I put a patch in the tracker that implements groups
> Jared> in the SVG backend. Is that the preferred way to submit
> Jared> patches, or should I just mail them?
> 
> Since we're just talking about a single file, I think mailing them
> directly to me is the easiest way for now. BTW, the attachment didn't
> go through on the Tracker.
> 
Oops...the groups patch is hopefully attached to this message.
> Jared> I've also been working on images. SVG has an image tag
> Jared> where you can include a external .png file. I used some
> Jared> code from the GTK backend to save an image as a png, then
> Jared> included, as shown below.
> 
> I think you'll be better off following the lead of how backend PS
> handles image drawing, which has no GTK dependence. I don't think you
> need to use GTK or PNG as an intermediary. You may want to get a
> fresh CVS checkout because there was a screwup in the width/height
> dimensions in earlier versions that has been fixed.
I don't see any obvious way to directly include a bitmap in SVG, but
I'll keep looking.

>>>>> "Jared" == Jared Wahlstrand <wah...@um...> writes:
 Jared> Hello, I put a patch in the tracker that implements groups
 Jared> in the SVG backend. Is that the preferred way to submit
 Jared> patches, or should I just mail them?
Since we're just talking about a single file, I think mailing them
directly to me is the easiest way for now. BTW, the attachment didn't
go through on the Tracker.
 Jared> I've also been working on images. SVG has an image tag
 Jared> where you can include a external .png file. I used some
 Jared> code from the GTK backend to save an image as a png, then
 Jared> included, as shown below.
I think you'll be better off following the lead of how backend PS
handles image drawing, which has no GTK dependence. I don't think you
need to use GTK or PNG as an intermediary. You may want to get a
fresh CVS checkout because there was a screwup in the width/height
dimensions in earlier versions that has been fixed.
Glad to see you're making progress! 
JDH

Hello, I put a patch in the tracker that implements groups in the SVG
backend. Is that the preferred way to submit patches, or should I just
mail them?
I've also been working on images. SVG has an image tag where you can
include a external .png file. I used some code from the GTK backend to
save an image as a png, then included, as shown below.
def draw_image(self, x, y, im):
 """
 Draw the Image instance into the current axes; x, y is the
 upper left hand corner of the image
 """
 rows, cols, s = im.as_str()
 X = fromstring(s, UInt8)
 X.shape = rows, cols, 4
 pb=gtk.gdk.Pixbuf(gtk.gdk.COLORSPACE_RGB,
 has_alpha=1, bits_per_sample=8,
 width=cols, height=rows)
 try: pa = pb.get_pixels_array()
 except AttributeError: pa = pb.pixel_array
 pa[:,:,:] = X
 gc = self.new_gc()
 pb.save('test.png','png')
 self._draw_rawsvg('<image x=\"%f\" y=\"%f\" width=\"%f\"
height=\"%f\" xlink:href=\"test.png\"></image>' % (x, self.height-y,
cols, rows))
The above works for 'image_demo2.py' in the examples. The downside of
this approach is that it would make the SVG backend dependent on GTK.
Can anyone think of a better way?
I was thinking of naming the png files 'filename_1.png',
'filename_2.png', etc. for each image in the figure, where
'filename.svg' is the name of the main file. What do you think?
jared

On 8 Jun 2004, at 13:51, Kirill Lapshin wrote:
> Jeremy,
>
> Thanks for fast response.
>
>>
>> I'm assuming that you're running from the console in the recommended 
>> way (i.e pythonw file.py -dWX).
>
> Not really. I am mostly interested in interactive usage, hence I am 
> simply firing python or ipython from console, and then in python shell 
> issuing couple of commands like:
>
> >>> from matplotlib.matlab import *
> >>> plot((1,2,3))
You probably want.
import matplotlib
matplotlib.interactive(True)
matplotlib.use('WX')
from matplotlib.matlab import *
plot([1,2,3])
See the explanation a bit further down.
>
>> I am not surprised that you are having problems running the Wx 
>> backend from Idle and/or PythonWin. It is generally problematic to 
>> launch a GUI app from an application which uses a different GUI 
>> backend (e.g a Wx app from Idle (which is Tk)) as the event loops get 
>> in each others' way. There are a few things I have to fix in the 
>> window close code for Wx anyway (it's broken in some respects) - for 
>> the moment the recommended way is to use the 'close window' button.
>
> Oh, I see. That explains it. I tried it from PyCrust and it does work 
> much better, though still there are some rough edges. Interactive mode 
> works, which is the most important one for me, but non-interactive 
> does not return back to python prompt after show() command, also 
> cursor turns into hourglasses when it is over plot window. Looks like 
> there are still some problems with message loop.
There are a couple of issues I keep meaning to get around to fixing. 
One problem is that I don't really use interactive mode, so I don't 
notice things so much in that area (not that this is an excuse...). The 
key difficulty is that the mainloop behaves subtly differently when 
running interactively and from a script. Every time I make one work 
correctly, it seems to break the other in unpredictable ways.
>> However, I'm quite concerned that launching from the Windows console 
>> causes problems. It should work correctly, provided that python is on 
>> the path and WxPython is installed correctly in site-lib.
>
> Yes, python is on the path, wxPython installed correctly in 
> site-packages. So what is the deal with "recommended way" of running 
> from console? pythonw will detach from console, but what -dWX do? It 
> is passed as an argument to script, so looks like it is responsibility 
> of the script to use it. Does that mean that WX backend can not be 
> used from regular console python shell? That would be quite 
> unfortunate, because for example IPython only runs interactively on 
> console.
The -dWX option tells matplotlib to use the Wx renderer to run the 
script. You can also set the preferred default renderer in the 
matplotlibrc file. As installed, I think this defaults to GtkAgg, but 
you can change it (see 
http://matplotlib.sourceforge.net/.matplotlibrc).
Your other option is to follow 
(http://matplotlib.sourceforge.net/interactive.html) and do
import matplotlib
matplotlib.interactive(True)
matplotlib.use('WX')
from matplotlib.matlab import *
plot([1,2,3])
...
This has the effect of hard-wiring the backend before importing the 
remainder of the matplotlib symbols.
>
>> I'd recommend boa-constructor 
>> (http://boa-constructor.sourceforge.net) for debugging Wx code. It's 
>> a pretty decent IDE, contains the best debugger I've yet found for 
>> Python, and is based on the Wx toolkit, so doesn't have the event 
>> loop issue mentioned above.
>
>
> Last time I checked Boa, it was quite buggy. Maybe it is time to give 
> it a second try. Thanks for the pointer.
Boa is quite buggy in places, and imposes its own way of working with 
Wx that doesn't suit me (at least for larger projects). However, the 
debugger is worth the effort.
> I am hoping someone familiar with TkAgg backend will step out and help 
> with Tk problems.
>
> BTW, since decision which backend to use depends quite a lot on 
> program you are running matplotlib from, would it be possible to 
> autodetect host program and choose appropriate backend?
We've looked at different ways to deal with the mainloop problem, but 
it is difficult to find a portable approach. It would probably be quite 
straightforward to look at sys.argv and issue a different 
matplotlib.use() call from there. Not sure that this would be easy to 
generalise (as there are so many possible shells).
In the longer term, John Hunter has been looking at putting the GUI 
into a separate thread, to avoid mainloop problems. A partial solution 
exists within scipy for this, but only applies, if memory serves, to Wx 
only, whereas we would need a solution for all backends. We're aware 
that this is quite annoying, although to be honest I think that most 
people use only one backend with their preferred tools.
Regards
Jeremy

>>>>> "Kirill" == Kirill Lapshin <ki...@la...> writes:
 Kirill> Oh, I see. That explains it. I tried it from PyCrust and
 Kirill> it does work much better, though still there are some
 Kirill> rough edges. Interactive mode works, which is the most
 Kirill> important one for me, but non-interactive does not return
 Kirill> back to python prompt after show() command, also cursor
 Kirill> turns into hourglasses when it is over plot window. Looks
 Kirill> like there are still some problems with message loop.
This isn't too surprising. One thing show does in backend_wx is
 if not matplotlib.is_interactive():
 wxapp.MainLoop()
Ie, if you issue show and you are not in interactive mode, you'll have
dualing wx mainloops. Moral of the story - make sure your IDE toolkit
matches your backend toolkit and set interactive : True in
matplotlibrc if you want to work interactively. All other
combinations are expected to fail.
 >> However, I'm quite concerned that launching from the Windows
 >> console causes problems. It should work correctly, provided
 >> that python is on the path and WxPython is installed correctly
 >> in site-lib.
 Kirill> Yes, python is on the path, wxPython installed correctly
 Kirill> in site-packages. So what is the deal with "recommended
 Kirill> way" of running from console? pythonw will detach from
 Kirill> console, but what -dWX do? It is passed as an argument to
 Kirill> script, so looks like it is responsibility of the script
 Kirill> to use it. Does that mean that WX backend can not be used
 Kirill> from regular console python shell? That would be quite
 Kirill> unfortunate, because for example IPython only runs
 Kirill> interactively on console.
No, in general, the only backend that can be used from a regular
console python shell is tkagg. To use GTK* interactively, you need to
use one of the GTK shells described on
http://matplotlib.sourceforge.net/interactive.html and to use WX
interactively you need pycrust or another wxpython shell. This is a
threading issue. Unfortunately, getting the standard python shell to
play nicely with GUI threading is not trivial. The best attempt thus
far is scipy's gui_thread which according to some reports is still
immature and is definitely not generic across GUI toolkits.
 Kirill> I am hoping someone familiar with TkAgg backend will step
 Kirill> out and help with Tk problems.
See Todd's suggestions on the user list. I think you should have no
trouble with ipython or the standard python shell with the following
settings in matplotlibrc
backend : TkAgg 
interactive : True
tk.window_focus : True
This last setting doesn't play nice with IDLE if I recall correctly so
use with caution. If you encounter troubles with this combination
please let us know.
 Kirill> BTW, since decision which backend to use depends quite a
 Kirill> lot on program you are running matplotlib from, would it
 Kirill> be possible to autodetect host program and choose
 Kirill> appropriate backend?
We've talked about it before. It shouldn't bee too hard to inspect
sys.modules and figure this out. I'm not sure how it should be
handled vis-a-vis matplotlibrc. Perhaps we a new default
backend : Auto
which 
 1) Inspects sys.modules to see if a GUI toolkit is loaded and uses
 it if so
 2) Otherwise tries to load systematically load gui toolkits in a
 platform dependent manner (wxpython or tk for enthought/win32,
 gtk for linux, etc) and with success sets the backend
 3) falls back on Agg or a warning if all three fail
Of course if the user explicitly sets the backend this pathway would
be ignored.
I'm on the fence as to whether this is a good idea. If we automate
too much it becomes more difficult to figure out what is going on in
case of problems, and it prevents users from figuring out how to
customize and control matplotlib. On the other hand, if people throw
up their hands in disgust with repeated failures and complexities,
that is a bad thing.
JDH

Jeremy,
Thanks for fast response.
>
> I'm assuming that you're running from the console in the recommended 
> way (i.e pythonw file.py -dWX).
Not really. I am mostly interested in interactive usage, hence I am 
simply firing python or ipython from console, and then in python shell 
issuing couple of commands like:
 >>> from matplotlib.matlab import *
 >>> plot((1,2,3))
> I am not surprised that you are having problems running the Wx backend 
> from Idle and/or PythonWin. It is generally problematic to launch a 
> GUI app from an application which uses a different GUI backend (e.g a 
> Wx app from Idle (which is Tk)) as the event loops get in each others' 
> way. There are a few things I have to fix in the window close code for 
> Wx anyway (it's broken in some respects) - for the moment the 
> recommended way is to use the 'close window' button.
Oh, I see. That explains it. I tried it from PyCrust and it does work 
much better, though still there are some rough edges. Interactive mode 
works, which is the most important one for me, but non-interactive does 
not return back to python prompt after show() command, also cursor turns 
into hourglasses when it is over plot window. Looks like there are still 
some problems with message loop.
> However, I'm quite concerned that launching from the Windows console 
> causes problems. It should work correctly, provided that python is on 
> the path and WxPython is installed correctly in site-lib.
Yes, python is on the path, wxPython installed correctly in 
site-packages. So what is the deal with "recommended way" of running 
from console? pythonw will detach from console, but what -dWX do? It is 
passed as an argument to script, so looks like it is responsibility of 
the script to use it. Does that mean that WX backend can not be used 
from regular console python shell? That would be quite unfortunate, 
because for example IPython only runs interactively on console.
> I'd recommend boa-constructor (http://boa-constructor.sourceforge.net) 
> for debugging Wx code. It's a pretty decent IDE, contains the best 
> debugger I've yet found for Python, and is based on the Wx toolkit, so 
> doesn't have the event loop issue mentioned above.
Last time I checked Boa, it was quite buggy. Maybe it is time to give it 
a second try. Thanks for the pointer.
I am hoping someone familiar with TkAgg backend will step out and help 
with Tk problems.
BTW, since decision which backend to use depends quite a lot on program 
you are running matplotlib from, would it be possible to autodetect host 
program and choose appropriate backend?
Thanks,
Kirill.

Hello Kirill,
I'm the WX maintainer for Matplotlib, so hopefully can cover a couple 
of your issues with WX.
> WX/WXAgg -- both don't work from console -- show empty window, cursor
> turns in hourglass when it is over plot window. From GUI app
> (IDLE/PythonWin) it seems to work at first glance -- plot gets created,
> but the plot window can not be closed with either Alt-F4 or mouse. It
> just does not react on close command. Moreover, python objects
> corresponding to window seems to get destroyed when I try to close
> window, because if I do few plots commands without trying to close the
> window, new plots appear in first window, however as soon as I try to
> close the window (it won't close, remember?), new plots will open new
> window. That second window can be closed, but first one still remain
> unclosable.
I'm assuming that you're running from the console in the recommended 
way (i.e pythonw file.py -dWX).
I am not surprised that you are having problems running the Wx backend 
from Idle and/or PythonWin. It is generally problematic to launch a GUI 
app from an application which uses a different GUI backend (e.g a Wx 
app from Idle (which is Tk)) as the event loops get in each others' 
way. There are a few things I have to fix in the window close code for 
Wx anyway (it's broken in some respects) - for the moment the 
recommended way is to use the 'close window' button.
I tend to prefer to use the PyCrust console for Wx (it's part of the Wx 
distribution)
However, I'm quite concerned that launching from the Windows console 
causes problems. It should work correctly, provided that python is on 
the path and WxPython is installed correctly in site-lib.
> Any ideas how that can be fixed, work arounded, debugged? I am pretty
> comfortable with debugging Python code, but as I said I don't have C
> compiler yet, so can't debug extensions.
I'd recommend boa-constructor (http://boa-constructor.sourceforge.net) 
for debugging Wx code. It's a pretty decent IDE, contains the best 
debugger I've yet found for Python, and is based on the Wx toolkit, so 
doesn't have the event loop issue mentioned above.
Good luck
Jeremy