matplotlib-users Mailing List for matplotlib

John Hunter wrote:
> Yes, and along those lines for the GTK shell, we should use
> rcParams['backend'] to detect GTK versus GTKAgg and use whichever is
> in the rc file in the call to matplotlib.use.
Ok. I may take a first stab at this in a day or two, but no promises.
> good. As for problems with wx, I can't really say until we try.
I can :( I just tried, and the new code (which doesn't lock up gv), will 
never start if the backend chosen is WX. But it may be a matter of thread 
conflicts or something, since pygtk calls are still being made. Let's get 
Tk*/Gtk* working first, with a well-localized set of thread calls only when 
needed. With a clean enough base, putting the WX code in the right place 
should be reasonably easy. Perhaps Andrew (who wanted to hack matplotlib a 
bit) might help along in LA.
Cheers,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 >> push = self.shell.push # Code to execute in user's namespace
 >> lines = ["import matplotlib",
 ---> "matplotlib.use('GTKAgg')",
 >> "matplotlib.interactive(1)", "import matplotlib.matlab as
 >> matlab", "from matplotlib.matlab import *"] You might make the
 >> additional caveat in the docs about honoring rc settings that
 >> the default backend is overridden.
 Fernando> Well, actually I think we should honor the user's rc
 Fernando> choice, don't you? In fact, the ipython version does
 Fernando> this, so the equivalent here would be just to comment
 Fernando> out the line you highlighted.
Yes, and along those lines for the GTK shell, we should use
rcParams['backend'] to detect GTK versus GTKAgg and use whichever is
in the rc file in the call to matplotlib.use.
 Fernando> Cool. I'll integrate Antoon's and your fixes into the
 Fernando> 'real' (read ipython-based) code, and we'll play with
 Fernando> that a bit. Do you foresee any problems with the WX
 Fernando> backend? Right now I have global pygtk calls, but I
 Fernando> suppose those should be done only by the matplotlib
 Fernando> shell class IF Gtk is the chosen backend. 
Relocating the pygtk calls into the backend dependent section sounds
good. As for problems with wx, I can't really say until we try.
Thanks!
JDH

John Hunter wrote:
>>>>>>"Fernando" == Fernando Perez <Fer...@co...> writes:
> Fernando> ps. John, I think we almost have this nailed :)
> 
> Don't tempt the fates -- I got an X11 freeze. But I think I fixed it.
Hey, I said _almost_ :)
> def pre_interact(self):
> """Initialize matplotlib before user interaction begins"""
> 
> ---> import matplotlib.matlab
> 
> I don't think you want this, especially not here. Remember that all
> the matplotlib.use and matplotlib.interactive calls should be made
> *before* importing matplotlib.matlab (which is when the actual backend
> is imported)
Noted.
> push = self.shell.push
> # Code to execute in user's namespace
> lines = ["import matplotlib",
> ---> "matplotlib.use('GTKAgg')",
> "matplotlib.interactive(1)",
> "import matplotlib.matlab as matlab",
> "from matplotlib.matlab import *"]
> 
> You might make the additional caveat in the docs about honoring rc
> settings that the default backend is overridden.
Well, actually I think we should honor the user's rc choice, don't you? In 
fact, the ipython version does this, so the equivalent here would be just to 
comment out the line you highlighted.
> 
> map(push,lines)
> 
> # turn off rendering until end of script
> ---> matplotlib.matlab.interactive = 0
> 
> I'm pretty sure you mean matplotlib.interactive(0) -- ie, it's a
> function, not a variable, and it isn't in the matlab interface module.
> And don't you want to turn off interaction only if they load a file,
> and then turn it back on? Ie,
[...]
Ok. In fact, in the ipython-based version you and I have floated, this was 
alreadey fixed (by you). But I'll double-check as soon as I can get that done 
(probably this evening). I asked the pygtk crowd for help with the simpler 
pyint-gtk, which did NOT have our recent work, because it made it much easier 
for them to test without asking them to download CVS ipython.
> But with these changes, it works great! Here is my modified version
Cool. I'll integrate Antoon's and your fixes into the 'real' (read 
ipython-based) code, and we'll play with that a bit. Do you foresee any 
problems with the WX backend? Right now I have global pygtk calls, but I 
suppose those should be done only by the matplotlib shell class IF Gtk is the 
chosen backend. That part of the design needs a bit of polishing, and I may 
have to leave it til we meet at scipy'04. I still have to put my talks 
together for the meeting, so my hacking time will be very limited for the next 
two weeks.
But we _are_ close :)
Best,
f

>>>>> "Fernando" == Fernando Perez <Fer...@co...> writes:
 Fernando> thanks to Antoon Pardon from the pygtk mailing list, 
I told you those guys were brainy :-)
 Fernando> ps. John, I think we almost have this nailed :)
Don't tempt the fates -- I got an X11 freeze. But I think I fixed it.
 def pre_interact(self):
 """Initialize matplotlib before user interaction begins"""
---> import matplotlib.matlab
I don't think you want this, especially not here. Remember that all
the matplotlib.use and matplotlib.interactive calls should be made
*before* importing matplotlib.matlab (which is when the actual backend
is imported)
 push = self.shell.push
 # Code to execute in user's namespace
 lines = ["import matplotlib",
---> "matplotlib.use('GTKAgg')",
 "matplotlib.interactive(1)",
 "import matplotlib.matlab as matlab",
 "from matplotlib.matlab import *"]
 
You might make the additional caveat in the docs about honoring rc
settings that the default backend is overridden.
 map(push,lines)
 # turn off rendering until end of script
---> matplotlib.matlab.interactive = 0
I'm pretty sure you mean matplotlib.interactive(0) -- ie, it's a
function, not a variable, and it isn't in the matlab interface module.
And don't you want to turn off interaction only if they load a file,
and then turn it back on? Ie,
 # Execute file if given.
 if len(sys.argv)>1:
---> import matplotlib
---> matplotlib.interactive(0) # turn off interaction
 fname = sys.argv[1]
 try:
 inFile = file(fname, 'r')
 except IOError:
 print '*** ERROR *** Could not read file <%s>' % fname
 else:
 print '*** Executing file <%s>:' % fname
 for line in inFile:
 if line.lstrip().find('show()')==0: continue
 print '>>', line,
 push(line)
 inFile.close()
---> matplotlib.interactive(1) # turn on interaction
But with these changes, it works great! Here is my modified version
#!/usr/bin/env python
"""Multithreaded interactive interpreter with GTK and Matplotlib support.
Usage:
 pyint-gtk.py -> starts shell with gtk thread running separately
 pyint-gtk.py -mplot [filename] -> initializes matplotlib, optionally running
 the named file. The shell starts after the file is executed.
Threading code inspired by:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65109, by Brian
McErlean and John Finlay.
Matplotlib support taken from interactive.py in the matplotlib distribution.
Also borrows liberally from code.py in the Python standard library."""
__author__ = "Fernando Perez <Fer...@co...>"
import sys
import code
import threading
import pygtk
pygtk.require("2.0")
import gtk
try:
 import readline
except ImportError:
 has_readline = False
else:
 has_readline = True
class MTConsole(code.InteractiveConsole):
 """Simple multi-threaded shell"""
 def __init__(self,on_kill=None,*args,**kw):
 code.InteractiveConsole.__init__(self,*args,**kw)
 self.code_to_run = None
 self.ready = threading.Condition()
 self._kill = False
 if on_kill is None:
 on_kill = []
 # Check that all things to kill are callable:
 for _ in on_kill:
 if not callable(_):
 raise TypeError,'on_kill must be a list of callables'
 self.on_kill = on_kill
 # Set up tab-completer
 if has_readline:
 import rlcompleter
 try: # this form only works with python 2.3
 self.completer = rlcompleter.Completer(self.locals)
 except: # simpler for py2.2
 self.completer = rlcompleter.Completer()
 
 readline.set_completer(self.completer.complete)
 # Use tab for completions
 readline.parse_and_bind('tab: complete')
 # This forces readline to automatically print the above list when tab
 # completion is set to 'complete'.
 readline.parse_and_bind('set show-all-if-ambiguous on')
 # Bindings for incremental searches in the history. These searches
 # use the string typed so far on the command line and search
 # anything in the previous input history containing them.
 readline.parse_and_bind('"\C-r": reverse-search-history')
 readline.parse_and_bind('"\C-s": forward-search-history')
 def runsource(self, source, filename="<input>", symbol="single"):
 """Compile and run some source in the interpreter.
 Arguments are as for compile_command().
 One several things can happen:
 1) The input is incorrect; compile_command() raised an
 exception (SyntaxError or OverflowError). A syntax traceback
 will be printed by calling the showsyntaxerror() method.
 2) The input is incomplete, and more input is required;
 compile_command() returned None. Nothing happens.
 3) The input is complete; compile_command() returned a code
 object. The code is executed by calling self.runcode() (which
 also handles run-time exceptions, except for SystemExit).
 The return value is True in case 2, False in the other cases (unless
 an exception is raised). The return value can be used to
 decide whether to use sys.ps1 or sys.ps2 to prompt the next
 line.
 """
 try:
 code = self.compile(source, filename, symbol)
 except (OverflowError, SyntaxError, ValueError):
 # Case 1
 self.showsyntaxerror(filename)
 return False
 if code is None:
 # Case 2
 return True
 # Case 3
 # Store code in self, so the execution thread can handle it
 self.ready.acquire()
 self.code_to_run = code
 self.ready.wait() # Wait until processed in timeout interval
 self.ready.release()
 return False
 def runcode(self):
 """Execute a code object.
 When an exception occurs, self.showtraceback() is called to display a
 traceback."""
 self.ready.acquire()
 if self._kill:
 print 'Closing threads...',
 sys.stdout.flush()
 for tokill in self.on_kill:
 tokill()
 print 'Done.'
 if self.code_to_run is not None:
 self.ready.notify()
 code.InteractiveConsole.runcode(self,self.code_to_run)
 self.code_to_run = None
 self.ready.release()
 return True
 def kill (self):
 """Kill the thread, returning when it has been shut down."""
 self.ready.acquire()
 self._kill = True
 self.ready.release()
class GTKInterpreter(threading.Thread):
 """Run a gtk mainloop() in a separate thread.
 Python commands can be passed to the thread where they will be executed.
 This is implemented by periodically checking for passed code using a
 GTK timeout callback.
 """
 TIMEOUT = 100 # Milisecond interval between timeouts.
 
 def __init__(self,banner=None):
 threading.Thread.__init__(self)
 self.banner = banner
 self.shell = MTConsole(on_kill=[gtk.mainquit])
 def run(self):
 self.pre_interact()
 self.shell.interact(self.banner)
 self.shell.kill()
 def mainloop(self):
 self.start()
 gtk.timeout_add(self.TIMEOUT, self.shell.runcode)
 try:
 if gtk.gtk_version[0] >= 2:
 gtk.threads_init()
 except AttributeError:
 pass
 gtk.mainloop()
 self.join()
 def pre_interact(self):
 """This method should be overridden by subclasses.
 It gets called right before interact(), but after the thread starts.
 Typically used to push initialization code into the interpreter"""
 
 pass
class MatplotLibInterpreter(GTKInterpreter):
 """Threaded interpreter with matplotlib support."""
 def __init__(self,banner=None):
 banner = """\nWelcome to matplotlib, a matlab-like python environment.
 help(matlab) -> help on matlab compatible commands from matplotlib.
 help(plotting) -> help on plotting commands.
 """
 GTKInterpreter.__init__(self,banner)
 
 def pre_interact(self):
 """Initialize matplotlib before user interaction begins"""
 push = self.shell.push
 # Code to execute in user's namespace
 lines = ["import matplotlib",
 "matplotlib.use('GTKAgg')",
 "matplotlib.interactive(1)",
 "import matplotlib.matlab as matlab",
 "from matplotlib.matlab import *"]
 map(push,lines)
 
 
 # Execute file if given.
 if len(sys.argv)>1:
 import matplotlib
 matplotlib.interactive(0) # turn off interaction
 fname = sys.argv[1]
 try:
 inFile = file(fname, 'r')
 except IOError:
 print '*** ERROR *** Could not read file <%s>' % fname
 else:
 print '*** Executing file <%s>:' % fname
 for line in inFile:
 if line.lstrip().find('show()')==0: continue
 print '>>', line,
 push(line)
 inFile.close()
 matplotlib.interactive(1) # turn on interaction
if __name__ == '__main__':
 # Quick sys.argv hack to extract the option and leave filenames in sys.argv.
 # For real option handling, use optparse or getopt.
 if len(sys.argv) > 1 and sys.argv[1]=='-mplot':
 sys.argv = [sys.argv[0]]+sys.argv[2:]
 MatplotLibInterpreter().mainloop()
 else:
 GTKInterpreter().mainloop()

Hi all,
thanks to Antoon Pardon from the pygtk mailing list, I now have what appears 
to be a fully working interactive python console for gtk/matplotlib usage, 
which does NOT lock up when things like os.system('gv foo.eps &') are emitted.
I've attached it here, and it would be great if people could take it for a 
spin and let me know how it works. Just make it executable and run
./pyint-gtk.py -mplot
and it preloads matplotlib for you, honoring your .matplotlibrc settings 
(except that it forces matplotlib to interactive mode).
If this resists a few days of testing, I'll port the mods Anton made to the 
real ipython.
Best regards,
f.
ps. John, I think we almost have this nailed :)

>>>>> "Jon" == Jon Wright <wr...@es...> writes:
 Jon> Hi all, Is there a trick hidden somewhere for autoscaling one
 Jon> axis only? I am frequently plotting data which has a series
 Jon> of narrow peaks and a large dynamic range. After zooming on
 Jon> the x-axis to the region of interest, I'd like to have an
 Jon> option to make the y axis rescale for the data in that range
Just to make sure you know, with the new toolbar2 (matplotlib-0.61)
you can selectively scale the yaxis interactively by pressing the
pan/zoom button, and clicking and dragging your right mouse button
over the y axis while holding down the 'y' key. Ditto for pan with
the left button.
 Jon> only. Having flailed around in the source I have the feeling
 Jon> that this is possible, but I haven't quite fathomed out how
 Jon> to do it (I'm using matplotlib for an interactive plot
 Jon> embedded in a tk application). Essentially I want the
 Jon> appropriate magic spell to give me a bounding box in y for
 Jon> the current x axis limits. The things I tried so far always
 Jon> seem to give the bounding box for all the data points,
 Jon> including the ones which are not currently being plotted on
 Jon> the x range. Sorry if I've missed something obvious!
No you're not missing anything. I can give you an idea of how to hack
this though. The autoscaling is controlled by a tick locator, found
in matplotlib.tickers. There are a number of locators which derive
from the Locator base class. You can access the major tick locator of
a given axis with, for example
 locator = ax.yaxis.get_major_locator()
The locator has a method to compute the view limits
 vmin, vmax = locator.autoscale()
It uses a _transforms.Interval instance under the hood to get the data
limits dmin, dmax which gives the min and max range for your data on
that axis. Of course, this is the min and max for all the y data, not
just the data in the current xrange, which is your problem.
In order to solve this, your need to: 1) compute the data limits in
the current viewport, 2) set the limited data lim on the axis interval
instance, 3) use it to get the new autoscale limits, and 4) reset the
old data lim interval instance back to its original setting. Assuming
you know the y data lim in the xrange of interest (more on that later)
you would do (untested but should work barring an obvious screw up)
 interval = ax.yaxis.get_data_interval()
 savemin, savemax = interval.get_bounds()
 dmin, dmax = # compute the y data limits in this xrange as below
 interval.set_bounds(dmin, dmax)
 # the locator has a ref to the interval and so sees your changes
 ax.set_ylim(locator.autoscale()) # autoscale returns (vmin, vmax)
 
 # now reset the original data lim
 interval.set_bounds(savemin, savemax)
The only remaining thing is to get the ydata in xrange. This depends
on the kind of data you plotted, but let's assume it is from 'plot'
and thus your data are stored in Line2D instances. With a single line
(eg returned by the call) 'line, = plot(x,y)' (note the comma for
tuple unpacking) you can do
 import matplotlib.numerix as nx
 xmin, xmax = ax.get_xlim()
 xdata = line.get_xdata()
 ydata = line.get_xdata()
 ind = nx.nonzero(mx.logical_and(nx.greater_equal(xdata, xmin)
 nx.less_equal(xdata, xmax)))
 y = nx.take(ydata, ind)
 dmin, dmax = min(y), max(y)
 
 # and now set the data lim in the interval instance as indicated
 # above
Now that's the process for a single line. For multiple lines, all you
need to do is keep a running total of all the data to get the min/max
of all the lines. The function ax.get_lines() will return all the
data lines matplotlib uses. If you have scatters, pcolors and other
kinds of plots which may use collections and other data structures,
then more work would be needed still. However, you may have direct
access to your data, in which case you can just use that to extract
the ydata in the range.
BTW, there has been some discussion on the devel list recently about a
plugin feature to support easy customization and extension of the
toolbar. This kind of thing is a perfect candidate for that, because
you could create a plugin for 'autoscale y in the current xrange' and
we could place it in a contrib plugin dir that others could add to
their toolbar when they want.
Hope this helps,
JDH
 

> Hi Jean-Michel,
> 
> I spoke with with Paul Barrett (who wrote the font manager and has
> done a lot of work with fonts/text) about your problem and neither he
> nor I have any immediate insight into your problem, so I just wanted
> to let you know that we'll look into it and see if we can improve
> international / unicode support, but it may be a little while before
> we can solve this problem.
> 
> Thanks for letting us know.
> JDH
Hi JD,
That's ok, I must say that seeing the silence around my mail I 
understood that this should be the first time this kind of problem occurs!
I know that internationalization is not a simple issue so I would not be 
surprised if it is not quickly solved. Let me know if you need 
volunteers for testing.
JM. Philippe

>>>>> "Jean-Michel" == Jean-Michel Philippe <jea...@ir...> writes:
 Jean-Michel> Hi, I'm new to matplotlib which is really good job
 Jean-Michel> ;-) and I'm currently fighting against character
 Jean-Michel> encodings :-(. Being working under win2k/western
 Jean-Michel> Europe, I finally found on the web that using a cp850
 Jean-Michel> source encoding definition was working with 'print'
 Jean-Michel> only if you also encode your strings from cp1252!
 Jean-Michel> (for us/en users: windows uses cp1252 but the console
 Jean-Michel> uses cp850, this message was written using
 Jean-Michel> iso-8859-1). Example:
Hi Jean-Michel,
I spoke with with Paul Barrett (who wrote the font manager and has
done a lot of work with fonts/text) about your problem and neither he
nor I have any immediate insight into your problem, so I just wanted
to let you know that we'll look into it and see if we can improve
international / unicode support, but it may be a little while before
we can solve this problem.
Thanks for letting us know.
JDH

>>>>> "Sigve" == Sigve Tjora <pu...@tj...> writes:
 Sigve> Hi everyone, Is there any planned support for a Qt-backend?
 Sigve> We are using Qt in our project, and I would like to use
 Sigve> Matplot lib for plotting.
 Sigve> If there is not any support for Qt how hard would it be to
 Sigve> make it myself? Would it be best to base it on the Agg
 Sigve> backend, or should I make a native Qt backend? What is the
 Sigve> least work? Is it possible to write the whole backend in
 Sigve> Python or should I use C++ in addition?
Currently there is no QT backend, or one in the works, but it would be
nice. It is definitely much easier to base it on the agg backend and
is in fact *strongly encouraged* as that minimizes the amount of
maintenance required. 
Using C/C++ is an optional step. TkAgg and GTKAgg use it to get the
optimal transfer speed from the agg image to the GUI canvas. WXAgg
and FLTKAgg do not use it, and Gregory reports great performance for
FLTKAgg. WXAgg uses string methods to transfer the image and FLTKAgg
uses a python buffer object. I encourage you to try and use a python
buffer object (or string method) as opposed to extension code in the
beginning since it's easier to write and maintain, it will introduce
no extra compile time dependencies, and in the event that you find it
too slow and want to write an extension to speed things up, you'll
have the pure python method to fall back on for users who can't get
the extension compiled.
matplotlib.backends.backend_template contains the basic documentation
for backend writers. But this code does a lot more than you need,
since agg will be doing the drawing; ie you don't need to implement a
renderer or graphics context. I recommend you give it a read through,
and then follow the lead of backend_fltkagg. I also advise you not to
implement the classic navigation toolbar (at least not until later)
because the new toolbar design is not only better (in my opinion),
it's currently the default and most importantly, is much easier to
implement since all the work is done for you in backend bases. You
basically need to load up some images into a toolbar and get the
signal connections right.
In the event you need a different pixel format to transfer the agg
image to the qt canvas, that will be no problem. I will be glad to
add it for you or you can add it yourself to backend_agg.
The only thing I ask of submitters is that if you want your backend to
be included with the matplotlib distribution, please be responsible
for testing it across the major platforms the GUI should run on (eg
linux, win32, and OSX), provide some install instructions, version
dependencies, etc, for the documentation, and monitor the mailing
lists to handle questions about your backend. In a nutshell, I need
you to maintain it. If you don't have the time to maintain it but
want to write one anyway for your own work, I would be happy to
provide a link to it with a disclaimer that users are on their own.
Good luck if you decide to do it, and let me know if I can help.
JDH

Hi all,
Is there a trick hidden somewhere for autoscaling one axis only? I am 
frequently plotting data which has a series of narrow peaks and a large 
dynamic range. After zooming on the x-axis to the region of interest, 
I'd like to have an option to make the y axis rescale for the data in 
that range only. Having flailed around in the source I have the feeling 
that this is possible, but I haven't quite fathomed out how to do it 
(I'm using matplotlib for an interactive plot embedded in a tk 
application). Essentially I want the appropriate magic spell to give me 
a bounding box in y for the current x axis limits. The things I tried so 
far always seem to give the bounding box for all the data points, 
including the ones which are not currently being plotted on the x range. 
Sorry if I've missed something obvious!
Thanks in advance,
Jon

On Wed, 2004年08月18日 at 21:45, Dominique Orban wrote:
> Great, this is doing the job nicely, thanks ! I am not very clear as to 
> what the 'subs' argument really does. In your example:
> 
> > #full control
> > gca().set_xscale('log',base=100,subs=[10,20,50])
> > #Major tick every 16**i, minor tick every subs*16**i
> 
> (16 should be 100 right?).
oooouuuups, yes indeed, sorry!
> There's a major tick at 100, 100^2, 100^3, 
> etc. And you're saying there are minor tick marks at 10*100*i ?!?
hum, not really, minor tick every array([10,20,50])*100**i (I use array
else python (and maybe some reader too familiar with python lists) may
think I mean [10,20,50] concatenated 100**i with itself...that could be
a very long list indeed ;-) )...
So minor ticks at
...0.001,0.002,0.005,0.1,0.2,0.5,10,20,50,1000,2000,5000,...
> What if you'd want tick labels [0, 1, 2, 3, 4, ...] instead of (in base 
> 2, say) [1, 2, 4, 8, 16, ...] ? 
> Is that easily done? I tried to obtain 
> it based on the example custom_ticker1.py (in the examples 
> subdirectory), but haven't been successful so far.
You mean tick labels like a linear plot, but with log ticking? (and
beware of 0, I doubt you will be able to see the 0 label in a log plot
except if you do a *LOT* of paning ;-) ;-P )
If yes, this is not yet possible, because only "major" ticks (the one
corresponding to base**i) are labeled, and what you want is labeling of
all ticks...this would be feasible when I cleanup minor/major ticking
for logscale, in the meantime I added a flag to logformatter to tell
"label all ticks" instead of "label only major ticks".
Then, to do what you want (or what I believe you want ;-) ),
simply do 
gca().set_xscale('log',base=1000,label_minor=True).
the base should be large enough so that your whole xrange is in it, and
by default minor tick will be generated every unit.
Be aware though that due to log spacing, last labels could be very close
to each other and this ain't pretty ;-) That's why I allowed full
control on minor ticks with subs, often you do want to carefully choose
which ticks you want, because you can end up with a black mes of ticks
and labels on the right of your graph if you don't...
> Thanks A LOT for the update of axes.py and ticker.py,
you're welcome,
Greg.

Hi John,
Thanks very much for attending to the errorbar bar-ends. FYI, I ran the p=
atched code over my own errorbar plots and the refactoring seems to work =
correctly in all cases.
kudos,
Gary
> As Gary noted, recently we changed the way error bars were drawn which
> apparently had some unintended consequences. The root of the problem
> is related to one that came up earlier on the list about differences
> in the way regular lines and marker lines are handled.
<snip>
> Replace matplotlib.axes.Axes.errorbar with the code below. Errorbar
> users, I would be much obliged if you test this. I tried all of
> Gary's errorbar_demo examples and they appeared to work fine....
--=20
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm

On Wed, 2004年08月18日 at 20:45, Paul Barrett wrote:
> Nor Pirzkal wrote:
> > 
> > I really like the way matplotlib has been turning out. As a Mac 
> > user, I was wondering how portable to Aquaterm the entire thing might 
> > be. Any idea if a aqua front-end is in the work. While tcl/tk WX etc.. 
> > works well under OSX, it is a lot of stuff to have to compile and 
> > install for a plotting package.
> 
> No. There is currently no Aqua front-end being developed that I am aware of.
> 
> Have you any interest in developing one for Aqua? I'd suggest an AquaAgg/MacAgg 
> backend, i.e. use Agg to do the rendering and Aqua to do the windowing, such as 
> is done with GtkAgg, WXAgg, and TkAgg. Once the GUI wrapper is done, most of 
> matplotlib comes along for free.
Hi,
I confirm this, I wrote an fltkAgg backend without much experience of
matplotlib or gui programming to start with, by modification of an
existing *Agg (TkAgg, which is the best to start with as GtkAgg and
WXAgg have non-Agg version, and inherit most of their windowing methods
from the non-Agg version...so a copy and modify approach is not as
easy)...This took me a few days, some used for extending fltk and agg
for speed optimization...So I guess, except if Aqua is really different
from other toolkit, it should be a 1-2 day work for any Aqua/python
guru, at most :-)
So, any volunteer? ;-)
Greg.

Hi everyone,
Is there any planned support for a Qt-backend? We are using Qt in our 
project, and I would like to use Matplot lib for plotting.
If there is not any support for Qt how hard would it be to make it myself? 
Would it be best to base it on the Agg backend, or should I make a native 
Qt backend? What is the least work? Is it possible to write the whole 
backend in Python or should I use C++ in addition?
Thanks,
Sigve Tjora

On Wed, 2004年08月18日 at 15:02, Mark Howson wrote:
> Hi,
> 
> Is there any easy way of adding missing points to a (line) plot? Matlab 
> can do this using NaN, but as far as I can tell matplotlib doesn't 
> support this.
This would be very nice. Gnuplot has a similar characteristic: to
create the plots at http://www.csun.edu/sfo, I use a trick like this:
f(x) = (x==-999999 ? 1/0 : x)
plot "file" using 1ドル:(f(2ドル))
so that an equally spaced time series appears with gaps where we have
missing data.
Hmmm...is this something which should be supported via masked arrays? I
tried plotting a masked array with matplotlib and numarray's MA package,
and found matplotlib checks for the existence of a mask but throws an
exception if you try to plot it.