On 05/16/2011 09:32 AM, Benjamin Root wrote:
>
>
> On Mon, May 16, 2011 at 2:08 PM, Benjamin Root <[email protected]
> <mailto:[email protected]>> wrote:
>
>
>
> On Mon, May 16, 2011 at 1:35 PM, Eric Firing <[email protected]
> <mailto:[email protected]>> wrote:
>
> On 05/16/2011 06:56 AM, Benjamin Root wrote:
> >
> >
> > On Tue, May 10, 2011 at 12:53 PM, John Hunter
> <[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>> wrote:
> >
> >
> >
> > On Tue, May 10, 2011 at 12:48 PM, Benjamin Root
> <[email protected] <mailto:[email protected]>
> > <mailto:[email protected] <mailto:[email protected]>>> wrote:
> >
> >
> >
> >
> > The one thing I am confused about is what file to
> edit for the
> > main page. I must be very dense because I just
> simply can not
> > figure out where the main page is generated from. I
> have been
> > meaning to fix some things on the front page for a
> while now,
> > but have been too afraid to ask.
> >
> >
> > see doc/_templates/*.html
> >
> > After you have integrated the pull request into the 1.0.x
> branch
> > (which is what I build the website from) I'll build and
> push it to
> > the sf site.
> >
> >
> > Sorry it took so long. I have made those immediate fixes and
> pushed
> > them up to my pull request. If there are any other doc fixes
> we want to
> > make, now would be a good time to do it.
>
> Ben,
>
> Would you add widget.py to the autogenerated API docs, please,
> unless
> there is some reason for it to be excluded? I happened to
> notice that
> it is missing; I haven't checked for other missing modules.
>
> Thank you.
>
> Eric
>
>
> No problem. Having a quick view through the docs, here is what I
> see as missing. Maybe some of these don't need to be included?
>
>
> bezier.py
> blocking_input.py
> contour.py
> finance.py
> fontconfig_pattern.py
> hatch.py
> image.py
> legend.py
> lines.py
> mpl.py
> offsetbox.py
> patches.py
> patheffects.py
> pylab.py
> pyparsing.py
> quiver.py
> scale.py
> table.py
> texmanager.py
> textpath.py
> text.py
> tight_bbox.py
> transforms.py
> widgets.py
>
> Some of these might not be "modules" per se, I was just doing a
> quick comparison of what rst docs we have and what we have in
> lib/matplotlib. Note, we are also missing api docs for backends
> "cairo", "cocoaagg", "emf", "fltkagg", "gdk", "gtkcairo", "gtk",
> "macosx", "mixed", "ps", "qt4", "qtagg", "qt", "svg", "tkagg", and
> "wx". Again, some of these might be redundant, I am just noticing
> differences between the available rst docs and the listed modules.
>
> Also, I noticed that nxutils_api.rst is pretty much useless. Should
> I fix that?
>
> Ben Root
>
>
>
> Corrections....
>
> fontconfig_pattern is included in font_manager_api.rst
> legend, lines, patches and text are included in artist_api.rst.
> However, legend is not included for the inheritance diagram.
Aha!
So, part of the problem here is that the contents list for "The
Matplotlib API" is full of names like "matplotlib_axes", which is a
module, and "matplotlib_artists", which documents a hierarchy of modules
inheriting from Artist--but by no means all such modules, since others,
like collections, stand alone. First, having all those "matplotlib_"
prefixes is distracting and makes it harder to find the information.
Second, the overall hierarchy is very inconsistent, with big categories
("artists") alongside details ("gridspec").
>
> Also, 'spines' is listed as 'spine'. I don't know if that impacts
> anything, but I am a stickler for consistency. Should this be fixed?
Yes.
Eric
>
> Ben Root
>
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
>
>
>
> _______________________________________________
> Matplotlib-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Matplotlib-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel