Fernando Perez, of ipython fame, has begun working on incorporating a
matplotlib environment into ipython. I've been experimenting with his
current framework "pylab" and it's very nice for interactive use.
Fernando is now subscribed to the dev list as well, so I thought I
would post some excerpts here in case anyone has any comments or
additional suggestions.
################ Interactive feature requests #################
> Gnuplot-like interactive features
> If you haven't used a recent release of gnuplot (4.0),
> I'd encourage you to play with it to steal a few ideas.
> While I'd really like to transition to matplotlib as soon
> as possible, there are some things which the recent
> gnuplot does _really well_ in terms of interactive usage
> (which combined with ipython is very efficient). I'll
> mention the ones I've come to rely on completely,
> hopefully something like this could improve the
> matplotlib interactive experience in the future.
> I really like systems where single keystrokes (no Ctrl-
> chords of any type) do useful things, when typed input is
> meaningless otherwise. Once you learn these keystrokes,
> using such interfaces is _extremely_ efficient and
> pleasant.
> - Quick logscaling : l for y axis, L for axis closest to mouse.
> - Quick grid toggle: g.
> - Better zooming: define a rectangle to zoom in, and have
> a 'zoom stack' one can walk up and down, as well as an
> autoscale button/keypress. All these work great in
> Gnuplot 4.0 (p/n for previous/next in the zoom stack, and
> a for autoscaling)
> - Show always at the bottom of the screen the x,y
> coordinates of the mouse, and allow single-button pasting
> of a text label with these coordinates on the plot.
> Being able to toggle a grid and logscales with just two
> keystrokes, and then zoom into a tricky part of a plot
> with a single drag of the mouse to draw the enclosing
> rectangle, is so much more efficient than typing at a
> prompt all the necessary commands... For scripted use
> obviously this doesn't matter, but interactive numerical
> work can be very efficient if the tools offer enough
> 'compact' ways of getting things done. This is one of
> the things which IPyhton tries to do: pack as much 'punch
> per keystroke' as possible.
All good suggestions. This brings us back to our ongoing discussion
of doing event handling across GUIs. I think overloading connect in
each of the canvases is viable. I added connect to wx and implemented
mouse move and button press there. Now the new
examples/coords_demo.py works on all three GUIs. Should be relatively
easy to extend this to handle key-presses etc to incorporate some of
the features discussed above.
################ mathtext PS ################################
> mathtext support in the PostScript backend? I've read
> your recent thread on the topic, but I wonder if you have
> a timeline for this, and if there's any hope of it
> happening sooner rather than later. I _loved_ the
> mathtext plots, but unfortunately for academic use, proper
> PostScript support is an inescapable necessity.
Paul, I told him you were working on this. Any progress?
################ pylab IPython profile #################
> I've attached an ipython profile to load matplotlib and
> friends into ipython 'ready to go'. Just put these two
> files into your ~/.ipython directory, and start 'ipython
> -p pylab' to get a TkAgg-based interactive environment
> ready to go. I'd like some feedback from you on this,
> and if you like it, I can include this for shipping in
> the next ipython release.
I'm attaching the two files below. Some changes will be required to
make these play nicely with numerix. You can test it out with
> ipython -p pylab
Because ipython does output cacheing ala mathematica, you can access
old return values that you may not have saved but now want to
customize, eg return lines from a plot commands; eg,
In [12]: plot([4,5,6])
Out[12]: [<matplotlib.lines.Line2D]
In [13]: some_more_plotting_commands...
You can later go back and set the line props with the cacued output
from line 12
In [18]: set(_12, 'color', 'r')
which is *very* useful! pylab attachments at end of email
############## ipython-based GTK-aware interactive shell ##########
> This one is just a proposal. I looked at your
> interactive.py code, and I think I could make a version
> of ipython which implements the threading trick needed to
> handle the gtk mainloop issue. What I'd like to know, is
> if you'd allow me to blatantly rip off whatever code I
> need from interactive.py (obviously maintaining all
> copyright and attribution notices). IPython is
> distributed as LGPL, so this would become part of the
> main ipython distro (it would be a standalone
> interpreter, probaby something like ipython-gtk).
> I think this could be a great system, since you'd get all
> the power and flexibility of ipython, with the ability to
> use the GTK frontend, which is a fair bit nicer than the
> Tk one.
> If you agree, I think I could give this a try over the
> next few weeks.
I for one, am very excited about the prospect of a good GTK based
interactive shell
############ Dynamic defaults #############
There was some discussion on how to best set the defaults (ie
dynamically change rc params). As discussed on this list in the past,
this will necessitate moving all the default initialization from
rcParams inside the __init__ functions rather than in the kwargs of
these function to defer setting the default until construction time
rather than module load time. This is easy but hasn't been done yet.
The lingering question is what kind of interface to provide to allow
easy customization of these attributes for interactive use.
rcParams['lines.linewidth'] = 2.0
would work but is overly burdonesome. We discussed providing some
aliases for the longer property names (lw for linewidth, ls for
linestyle, fc for facecolor, etc) and then providing a function that
takes a grouping string (eg 'lines', 'axes' or 'text') for the first
arg and then kwargs afterwards
defaults('lines', lw=2, color='r')
which would provide a fairly pithy interface to dynamically
configuring the rcparams.
########### A WX bug ################
Just an FYI for archival purposes, this one is apparently out of our
hands
> WX backends don't work at all. This is not matplotlib's
> or Fedora's problem, but rather a bug in WxWindows. See:
> http://sourceforge.net/tracker/index.php?func=detail&aid=915333&group_id=9863&atid=109
> 863
> ImportError: /usr/lib/wxPython/lib/libwx_gtk2ud-2.4.so: undefined symbol: _gtk_accel_group_detach
> Here's a traceback:
In [6]: import wx
ipythonrc-pylab (957 Bytes)
matplotlib_load.py (1.75 KB)
···
---------------------------------------------------------------------------
ImportError Traceback (most recent call last)
/home/fperez/<console>
/usr/lib/python2.3/site-packages/wx/__init__.py
43 __revision__ = "Revision: 1\.1\.2\.4 "[11:-2]
44
---> 45 from wxPython import wx
46
47 _newnames = {}
/usr/lib/python2.3/site-packages/wxPython/__init__.py
18 # Ensure the main extension module is loaded, in case the add-on modules
19 # (such as utils,) are used standalone.
---> 20 import wxc
21
22
#----------------------------------------------------------------------------
ImportError: /usr/lib/libwx_gtk2-2.4.so.0: undefined symbol:
_gtk_accel_group_detach
> Apparently the WX guys chose to use _gtk_* symbols which
> the GTK documentation _explicitly warned_ were private and
> could go away at any time. Now, in the version of GTK
> shipped with Fedora they _did_ go away, so Wx broke. This
> just needs to be fixed by the Wx team (maybe it already is
> in CVS, I'm using Wx as shipped with Fedora). So don't
> worry about this, it will get fixed in time by those
> responsible.
############ pylab attachments ##################