matplotlib-devel Mailing List for matplotlib

 Hi Russell (and Mike),
Is it useful in the long term to have such a packager? My impression is
that as soon as packaging is more robust we'll switch to using pip or
easy_install.
First off, sorry for the long email - got a bit carried away :-) The
summary is that I propose we keep the dmg installer but maybe make it use
the system Python for reasons illustrated below.
For the record, I'm using pip / easy_install to install matplotlib from
source on my Mac and that has been working fine for a while now. You only
need to add pkg-config (and the development tools, obviously) to a virgin
Mac system and this is now really easy in the days of Homebrew.
Of course, binary packages have the extra issue of a dependency on the
environment for which it is built, which complicates matters for binary
eggs (thanks for the reminder of wheel, Mike - definitely something to
watch). This is the main reason why I don't use the Mac installer dmg: it's
built for python.org Python and I prefer to use system Python instead.
(On this note, it would be interesting to find out how matplotlib people
get Python on their Mac these days. My gut feel tells me that Homebrew
Python will be quite popular these days, followed by EPD / Anaconda and
then maybe python.org Python. If you use Homebrew there is now the option
of "brew install matplotlib" courtesy of Samuel
John<https://github.com/samueljohn/homebrew-python/blob/master/matplotlib.rb>,
while EPD and Anaconda ship with their own versions of matplotlib, so most
of those users are taken care of.)
To answer your original question: I do see a use for a dmg installer in the
long term, but one you might not have considered. I picture a Mac user who
is not familiar with Python but wants to try out matplotlib (the image of
Justin Long saying "Hello, I'm a Mac" somehow comes to mind :-)).
Justin has never heard of easy_install or even a compiler and might not be
that comfortable with the Terminal. On the other hand, he is used to
installing software by downloading and clicking on a dmg or via the App
Store. This is a person who is starting out with these tools and needs as
few obstacles as possible to get going. Once he is up and running and likes
what he sees, he might be persuaded to install a more full-fledged Python
distribution or the rest of the SciPy stack.
As an experiment I put myself in the shoes of Justin. I actually did the
steps below on a spare MacBook Pro running Mac OS X 10.7.5 that was
unsullied by extra Pythons and rogue matplotlibs and what not.
<BEGIN EXPERIMENT>
Someone told me about "matplotlib" (maybe after seeing a plot in a talk or
a paper) which led me to matplotlib.org (first Google hit).
I see "Download" and go to the downloads
page<http://matplotlib.org/downloads.html>.
I see a bunch of links, including these two under "Latest stable version":
matplotlib-1.2.1-py2.7-python.org-macosx10.3.dmg
matplotlib-1.2.1-py2.7-python.org-macosx10.6.dmg
Since I am on Lion I guess I have to download the latter (although the fact
that it says 10.6 and not 10.7 worries me...). I'm not sure what the rest of
the filename means - what is py27-python.org? I download the dmg and open
it. I am impatient like most users and click on "Continue".
Oops, there is a problem. The third "Continue" button is grayed out with an
error that says: "matplotlib 1.2.1 can't be installed on this disk.
matplotlib requires System Python 2.7 to install." [This is ironic because,
unbeknownst to Justin, he actually *has* System Python 2.7 installed...] Time
to click on "Go Back"... Aah, Important Information (I kick myself for not
reading this): "matplotlib for MacOS X 10.6 or later [cool!] and 64-bit
Python 2.7 from python.org (not Apple's built-in Python)". So that's
probably what py2.7-python.org refers to. If Justin is patient enough he
might also spot the following line: "Before running matplotlib, you must
install numpy."
[Clicking "Go Back" would have been the more useful thing to do in this
case. If I had decided to return to matplotlib.org, I might have seen "Need
help?" and clicked on the "faq" link and ended up at the OS-X
Notes<http://matplotlib.org/1.3.0/faq/installing_faq.html#os-x-notes>.
This mentions "several alternative versions of python" such as EPD,
MacPython (yikes, Leopard only!) or python.org. But the installer only
works with the latter... Surprisingly enough I could not find *any* explicit
mention in the matplotlib installation docs that you need to install NumPy
first. EDIT: Oh wait, it's well documented
here<http://matplotlib.org/users/installing.html> but
I can only reach this important page by clicking on "docs" in the toolbar
below the page title and spotting the "Installing" link. Maybe the
"Download" section on the front page should read "Read the installation
instructions <http://matplotlib.org/users/installing.html> first and then
visit the matplotlib downloads page <http://matplotlib.org/downloads.html>
."]
Time to visit python.org. I see "Download" and then notice "Python 2.7.5
Mac OS X 64-bit/32-bit x86-64/i386 Installer (for Mac OS X 10.6 and later
[2])". I download the dmg and click on it. The installation is successful.
I go back to the matplotlib dmg and retry the installation - success!
Mmm, what now?
[This is not really matplotlib's problem, but I found surprisingly few
resources that tell you how to start Python on the Mac if you know
absolutely nothing about Unix and Terminals and such. If you search for
"python mac" on Google you at least get some idea at the first
hit<http://www.python.org/getit/mac/>.
The official Mac usage page <http://docs.python.org/2/using/mac.html> is
quite technical but mentions that "your best way to get started with Python
on Mac OS X is through the IDLE integrated development environment" which
at least gets you to a Python prompt.]
As a typical Mac user I expect that something has appeared in
/Applications. I see no matplotlib but at least there is a Python 2.7
folder. I click on "Python Launcher" which seems like the obvious place to
start. Nothing happens - oh wait, something has started but it doesn't do
much. I click on IDLE and this looks more promising. At least there is a
prompt that looks like the examples on the net. Alternatively I have
somehow found out how to run Python in the Terminal.
Next issue... I type "import matplotlib" and up comes "ImportError: No
module named numpy". A search reveals www.numpy.org. I click on "Getting
NumPy" and end up at the SciPy installation
page<http://www.scipy.org/install.html>.
It mentions Mac packages but only give an example for using Macports.
Otherwise it suggests installing a full Python distribution (What, start
from scratch? But I'm so close!).
Argh, this is becoming a PITA. [At this stage Justin might accidentally
install a compiler and enter a new world of hurt :-)] Oh well, the
interwebs to the rescue. Search for "numpy mac". The first hit is the
aforementioned page. The second
hit<http://stackoverflow.com/questions/7338051/install-numpy-on-mac-os-x-lion-10-7>looks
more promising, but contains many conflicting answers ("Lion comes
with numpy installed?"). If I'm lucky I might follow the last suggestion
which reveals the NumPy
SourceForge<http://sourceforge.net/projects/numpy/files/NumPy/>page.
Or I could read the Numpy User Guide (DRAFT) -> Building and
installing NumPy -> Mac OS X which points there too.
I assume I want the latest version (1.7.1) and I stumble upon
numpy-1.7.1-py2.7-python.org-macosx10.6.dmg. Hey, that has a familiar and
comforting filename! It installs without a hitch and finally "import
matplotlib" succeeds and I manage to make a plot from IDLE!
Now I need a drink...
<END EXPERIMENT>
This was quite an eye-opener for me (although I wish I could shut my eyes
again quickly and forget this ever happened :-)). Hopefully the typical
would-be matplotlib user is not as hapless as Justin, but I suspect that
quite a few need guidance. I guess their best chance for happiness is to
stumble upon a full-fledged Python distribution but if matplotlib is their
entry point to the Python universe they might be in for an adventure ride.
Although if I had read the proper matplotlib installation instructions
first I might have gone straight to EPD...
I picture the following basic Mac user groups:
- Black belt: pulls git repositories to get bleeding-edge packages,
compiles from scratch, lives in the Terminal, probably uses Homebrew Python
or EPD / Anaconda or some custom Python installation
- Savvy: likes to install packages via pip / easy_install, probably has a
compiler, not afraid of Terminal, probably uses Homebrew Python or EPD /
Anaconda or maybe even Macports / Fink Python
- No Fuss: likes to click on a dmg, has no compiler, rarely uses Terminal,
possibly has EPD / Anaconda or just system Python
- Justin: a hapless version of No Fuss :-)
The problem I see with the binary dmg installer is that it is currently
aimed somewhere between Savvy and No Fuss users. It won't help the Black
Belt and EPD / Anaconda users and is also not as straightforward as the No
Fuss user would have hoped.
This is why I'm wondering whether it would make more sense to base the dmg
installer on system Python instead. Since Lion ships with Python 2.7.1,
NumPy 1.5.1, libfreetype and libpng, OS X has had the potential since 10.7
to run matplotlib out of the box with no modifications or extra
dependencies (although the latest 1.3.0 might throw a spanner in the works
again by shedding dateutil, pytz and friends). A No Fuss user like Justin
could therefore click on the dmg as he does with all his other software
installations and matplotlib will "just work" like the OS X mantra says.
Having used system Python extensively for many years I can vouch that it is
more than adequate for someone wanting to try out matplotlib and sure is
easier to install!
Of course, maintaining the dmg installer is already a big job and your work
load is therefore probably the biggest factor in these discussions :-)
Best regards,
Ludwig

On 2013年08月01日 10:40 AM, Matt Terry wrote:
> Hi,
> I'm working on cleaning up the key-event callback code. What is the
> correct spelling of the control key? Is it "control" or "ctrl"?
> Different backends spell it differently. May I homogenize things at the
> expense of breaking code? Fwiw, the qt4 backend spells it both ways
> depending on the code path.
>
> -matt
Matt,
http://matplotlib.org/api/backend_bases_api.html#matplotlib.backend_bases.KeyEvent
It looks like the key is "control" but the modifier is "ctrl".
Eric

Hi,
I'm working on cleaning up the key-event callback code. What is the correct
spelling of the control key? Is it "control" or "ctrl"? Different backends
spell it differently. May I homogenize things at the expense of breaking
code? Fwiw, the qt4 backend spells it both ways depending on the code path.
-matt

(Apologies for cross-posting).
matplotlib has a dire need to improve its continuous integration
testing. I've drafted MEP19 and solicited comments, but there hasn't
been a lot of feedback thus far.
As an alternative to mailing list discussion, where this sort of upfront
planning can sometimes be difficult, I'm considering holding a Google
Hangout in the next few weeks on the subject. It's ok to participate
even if you don't have the time to work on matplotlib -- I would also
like feedback from advice from those that have configured similar
systems for other projects. matplotlib's needs are somewhat more
complex in terms of dependencies, cpu, ram and storage, so we're pushing
things pretty far here.
If there's enough people with an interest in participating in the
discussion, I'll send around a Doodle poll to find a good time.
Mike

(Apologies for cross-posting).
matplotlib has a dire need to improve its continuous integration 
testing. I've drafted MEP19 and solicited comments, but there hasn't 
been a lot of feedback thus far.
As an alternative to mailing list discussion, where this sort of upfront 
planning can sometimes be difficult, I'm considering holding a Google 
Hangout in the next few weeks on the subject. It's ok to participate 
even if you don't have the time to work on matplotlib -- I would also 
like feedback from advice from those that have configured similar 
systems for other projects. matplotlib's needs are somewhat more 
complex in terms of dependencies, cpu, ram and storage, so we're pushing 
things pretty far here.
If there's enough people with an interest in participating in the 
discussion, I'll send around a Doodle poll to find a good time.
Mike

Mike:
For some reason I didn't see your posts until now, apologies.
In fact, STIX is not supposed to "blend with" Times; rather, STIX
*replaces* Times wholesale -- i.e. they have redesigned the whole character
set. Thus labels (ticks, arbitrary text etc.) should also use STIX, even if
they don't use math.
I finally found the correct rcParams to use to achieve this:
from matplotlib import rcParams
rcParams["font.family"] = "STIXGeneral"
rcParams["mathtext.fontset"] = "stix"
It would certainly be nice if this could be done with a single setting.
It seems to me that given that STIX is already distributed with Matplotlib,
this could be a good new default to replace Bitstream Vera Sans.
On Mon, Jul 22, 2013 at 8:46 AM, Michael Droettboom <md...@st...> wrote:
> On 07/21/2013 04:12 AM, David P. Sanders wrote:
>
>
> Breaking news from the MathJax site:
>
> The *SVG output processor* is new in MathJax version 2.0, and it uses Scalable
> Vector Graphics to render the mathematics on the page.
>
>
> Not everything that views SVG is a web browser with Javascript support, so
> doing so would break using the SVG files in Inkscape and Adobe Illustrator,
> for example. I think that's kind of a non-starter, unfortunately.
>
>
>
> Mike: Could we use this to finally render all text in STIX *without*
> using an external TeX installation? This would be fantastic!
>
>
> You already can render all text in STIX without an external TeX
> installation. That's the purpose of the mathtext support in matplotlib. I
> agree it has the one wart that the default font also needs to be set when
> using stix for the math, but beyond that, it does already work today.
>
> Cheers,
> Mike
>
>
> David
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Matplotlib-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
>
>
-- 
Dr. David P. Sanders
Profesor Titular "A" / Associate Professor
Departamento de Física, Facultad de Ciencias
Universidad Nacional Autónoma de México (UNAM)
dps...@ci...
http://sistemas.fciencias.unam.mx/~dsanders
Cubículo / office: #414, 4o. piso del Depto. de Física
Tel.: +52 55 5622 4965

On 07/31/2013 07:40 PM, Russell E. Owen wrote:
> In article <51F...@st...>,
> Michael Droettboom <md...@st...>
> wrote:
>
>> On 07/31/2013 05:05 PM, Russell E. Owen wrote:
>>> In article <51F...@st...>,
>>> Michael Droettboom <md...@st...>
>>> wrote:
>>>
>>>> On 07/31/2013 01:47 PM, Russell E. Owen wrote:
>>>>> In article <51F...@st...>,
>>>>> Michael Droettboom <md...@st...>
>>>>> wrote:
>>>>>
>>>>>> I have tagged and uploaded matplotlib 1.3.0 final. Congratulations to
>>>>>> all involved! It was a long slog getting this release out, and I
>>>>>> appreciate everyone's patience.
>>>>>>
>>>>>> Once we have binaries uploaded to SourceForge, I will make a formal
>>>>>> announcement in the usual channels.
>>>>> I built the Mac binary on MacOS X 10.6 but have run into two problems:
>>>>> - Most of the unit tests are missing, so I can't properly test the
>>>>> results. But my application that uses matplotlib and TkAgg works fine,
>>>>> so may well be OK. Also, I checked and the installer was trying to build
>>>>> all expected backends (including the native Mac backend).
>>>> What do you mean the unit tests are missing? They don't run? Can you
>>>> send the output from nose?
>>> I have appended my test log. I don't know how to run the tests using
>>> nose, but will be happy to have a go with instructions. (Running
>>> "nosetests" in the matplotlib source dir does nothing useful).
>> Thanks. It's using nose under the hood, so that's exactly what I
>> meant. I should have been more clear.
>>
>> I'm not sure what might be causing this. As a sanity check (and maybe
>> you've already done this), have you tried doing "rm -rf matplotlib*" in
>> your site-packages directory?
It would be nice to get to the bottom of this puzzle. I'll start 
another thread to get the attention of other Mac developers in case 
they've seen it before.
>>
>>>> Glad to hear about the installer building the macosx backend -- that was
>>>> pretty serious when it wasn't doing that.
>>>>
>>>>> - When the 1.3.0 installer is used to overwrite matplotlib 1.2.1 (and
>>>>> the pytz and dateutil that it installs) it breaks pytz and dateutils, by
>>>>> deleting most of the contents, leaving only a subdir named zoneinfo in
>>>>> each package (with different contents for each package).
>>>>>
>>>>> Installing a new pytz and dateutils and running the 1.3.0 binary
>>>>> installer (overwriting matplotlib 1.3.0 or no matplotlib at all) leaves
>>>>> these packages functional (though it changes the modification date, so
>>>>> it's doing something).
>>>> I thought you were including pytz and dateutils in your installer. Is
>>>> that not the case? If not, isn't it enough to document that matplotlib
>>>> now doesn't ship with these dependencies, and they will need to be
>>>> installed using pip or other means? Can they be installed afterward and
>>>> have things work?
>>> matplotlib used to include pytz and dateutil in its installation. This
>>> seemed to be a very good thing overall, since it made sure the
>>> dependencies were satisfied, though it is possible that it occasionally
>>> overwrite a version the user would have preferred to have.
>> It also made it impossible to install security updates in those other
>> packages, which was a problem for Linux distros, MacPorts, homebrew, etc.
> I confess I'm surprised because this feature was disabled by default. I
> had to manually enable it whenever I made a binary installer by editing
> setup.cfg.
>
>>> In any case the matplotlib developers removed support for this feature
>>> in 1.3. As a result, binary installers now have to tell users to install
>>> these packages manually (as well as six and pyparsing). It may be
>>> possible to postprocess the Mac binary installer to install these
>>> packages, but I don't know how to do it.
>> I thought that was the solution we had arrived at in the earlier
>> discussion. I'm sorry if I misunderstood. If you "python setup.py
>> install" matplotlib into a fresh virtualenv, it will install all of
>> these dependencies. Then that virtualenv's site-packages directory can
>> be used as the basis for the contents of the installer. As I'm not a
>> Mac guy, and I don't understand how the installer is built, is there a
>> reason that wouldn't work?
> I build the Mac binaries using bdist_mpkg. I'm afraid I don't know how
> it works under the hood. It creates an "mpkg" binary installer in the
> dist subdirectory. To run tests, I install matplotlib (using that mpkg
> installer), since there isn't an obvious way to tests on the mpkg.
>
> I'm sure it's possible to accumulate all the files as you suggest and
> turn them into a binary installer, but I don't know how to do it.
Ok -- I didn't realize the bdist_mpkg was so tied into a single 
distutils package.
One possible way forward: pip has a pybundle option, so you can do:
 pip pybundle matplotlib.pybundle matplotlib
which will create a zip file (matplotlib.pybundle) containing a built 
matplotlib and all of its dependencies. Then it's just a matter of 
making an installer that puts those files in the right place. It 
doesn't seem like bdist_mpkg is the right tool for that, but there must 
be other tools on the Mac to make installers that juts put files somewhere.
>
> Is it useful in the long term to have such a packager? My impression is
> that as soon as packaging is more robust we'll switch to using pip or
> easy_install.
pip and easy_install already work now -- the problem is that the user 
needs to have a compiler and the headers for the C dependencies 
(freetype, libpng) installed. "wheels" are a new way to distribute 
binaries using pip, and I think that once that's readily available and 
robust, it will provide the best of both worlds -- the dependency 
resolution *and* the convenience of a binary installer.
>
>>> The problem is that under some circumstances the new installer may trash
>>> existing installations of python-dateutils and pytz. I consider that
>>> unacceptable. Why break things that are already installed?
>> Have you investigated how that's happening? There are no components by
>> that name in the current matplotlib, so they shouldn't be touched,
>> unless the old matplotlib was using .pth files for them or something, I
>> suppose, but I don't think it was by default. Have you investigated
>> what exactly the installer is clobbering? Maybe take a snapshot of the
>> site-packages tree before the installer and then using a tree diffing
>> tool to see what the differences are afterward.
> The old matplotlib was not using .pth files (at least I never found any
> in site-packages).
I'm still at a loss as to how the new installer, which includes nothing 
to do with python-dateutils and pytz other than importing them, could 
trash existing installations of those packages. I think the only way to 
find out is to compare the trees before and after to see what it's doing.
>
>>> In other words, we seem to have the worst of the old world and the new:
>>> don't install the new packages but perhaps break them if they already
>>> exist. Unfortunately breakage is likely to be the norm because most
>>> users will be upgrading from matplotlib 1.2.1.
>> I think we need to get to the bottom of why it's breaking the old
>> installations of pytz and dateutil. Then we can hopefully address
>> that. Does the installer try to uninstall what the old installer
>> installed first, perhaps?
> That is an interesting suggestion. I"m not an expert, but I thought mpkg
> files usually didn't know how to uninstall old files (though one can add
> scripts to do this).
>
>
I just wanted to ensure it's not doing anything magical that would cause 
the breakage, which it sounds like it's not.
Sorry this has been such a difficult transition -- I think we're getting 
there, slowly but surely, though.
Mike

I have made this little example image less wide directly on the website, 
and in the source in a1921d6216b0. It may take a few minutes for all of 
github's web servers to update the content.
Mike
On 07/31/2013 09:54 PM, Eric Firing wrote:
> On 2013年07月31日 8:02 AM, Michael Droettboom wrote:
>> The layout has changed, but sidebar has not. Can you provide a
>> screenshot? Note, you can always visit the older version of the website
>> athttp://matplotlib.org/1.2.1 for direct comparison.
> The problem is that the new layout only works with a wider window than
> was required for the old layout. I think this is a step backward.
>
> Eric
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel

On 08/01/2013 01:39 AM, Jason Grout wrote:
> On 7/31/13 8:17 PM, Michael Droettboom wrote:
>> On 07/31/2013 10:18 PM, Jason Grout wrote:
>>> On 7/31/13 2:05 PM, Russell E. Owen wrote:
>>>> As a result, binary installers now have to tell users to install
>>>> these packages manually (as well as six and pyparsing).
>>> I don't think six is mentioned in the "What's new" note for 1.3.0. It
>>> just details that pyparsing, pytz, and dateutil are now dependencies.
>>> Can you add six to the notes as well, if it is also moving to
>>> "dependency" status?
>>>
>> six is a dependency of dateutil. I don't know if we should be in the
>> business of listing all secondary dependencies -- when would we stop?
>>
> Given that six was distributed with matplotlib and is no longer being
> distributed (right?), I think it makes sense to list it. I would stop
> at the software that never was part of matplotlib.
>
Would you mind reviewing https://github.com/matplotlib/matplotlib/pull/2267?
Mike

On 7/31/13 8:17 PM, Michael Droettboom wrote:
> On 07/31/2013 10:18 PM, Jason Grout wrote:
>> On 7/31/13 2:05 PM, Russell E. Owen wrote:
>>> As a result, binary installers now have to tell users to install
>>> these packages manually (as well as six and pyparsing).
>> I don't think six is mentioned in the "What's new" note for 1.3.0. It
>> just details that pyparsing, pytz, and dateutil are now dependencies.
>> Can you add six to the notes as well, if it is also moving to
>> "dependency" status?
>>
> six is a dependency of dateutil. I don't know if we should be in the
> business of listing all secondary dependencies -- when would we stop?
>
Given that six was distributed with matplotlib and is no longer being 
distributed (right?), I think it makes sense to list it. I would stop 
at the software that never was part of matplotlib.
Thanks,
Jason

On 07/31/2013 10:18 PM, Jason Grout wrote:
> On 7/31/13 2:05 PM, Russell E. Owen wrote:
>> As a result, binary installers now have to tell users to install
>> these packages manually (as well as six and pyparsing).
> I don't think six is mentioned in the "What's new" note for 1.3.0. It
> just details that pyparsing, pytz, and dateutil are now dependencies.
> Can you add six to the notes as well, if it is also moving to
> "dependency" status?
>
six is a dependency of dateutil. I don't know if we should be in the 
business of listing all secondary dependencies -- when would we stop?
Mike

On 7/31/13 2:05 PM, Russell E. Owen wrote:
> As a result, binary installers now have to tell users to install
> these packages manually (as well as six and pyparsing).
I don't think six is mentioned in the "What's new" note for 1.3.0. It 
just details that pyparsing, pytz, and dateutil are now dependencies. 
Can you add six to the notes as well, if it is also moving to 
"dependency" status?
Thanks,
Jason

On 2013年07月31日 8:02 AM, Michael Droettboom wrote:
> The layout has changed, but sidebar has not. Can you provide a
> screenshot? Note, you can always visit the older version of the website
> athttp://matplotlib.org/1.2.1 for direct comparison.
The problem is that the new layout only works with a wider window than 
was required for the old layout. I think this is a step backward.
Eric

On 7/31/13 11:02 AM, Michael Droettboom wrote:
> The layout has changed, but sidebar has not. Can you provide a
> screenshot? Note, you can always visit the older version of the website
> at http://matplotlib.org/1.2.1 for direct comparison.
I just realized I had the webpage zoomed in (apple/control +), which was 
part of the problem. It looks great when I unzoom the page. Sorry for 
the false alarm.
I'm really excited about the webagg backend. Thanks for all your work 
on this release!
Jason

On 2013年07月31日 11:12 AM, Russell E. Owen wrote:
> All the interesting information about a build is printed at the
> beginning and soon scrolls out of sight, so it's usually not obvious if
> a build is missing something expected.
I think we could collect that information and re-print it to the screen 
at the end.
Eric