On Monday, May 16, 2011, Eric Firing <efir...@hawaii.edu> wrote:
> On 05/16/2011 09:32 AM, Benjamin Root wrote:
>>
>>
>> On Mon, May 16, 2011 at 2:08 PM, Benjamin Root <ben.r...@ou.edu
>> <mailto:ben.r...@ou.edu>> wrote:
>>
>>
>>
>> On Mon, May 16, 2011 at 1:35 PM, Eric Firing <efir...@hawaii.edu
>> <mailto:efir...@hawaii.edu>> wrote:
>>
>> On 05/16/2011 06:56 AM, Benjamin Root wrote:
>> >
>> >
>> > On Tue, May 10, 2011 at 12:53 PM, John Hunter
>> <jdh2...@gmail.com <mailto:jdh2...@gmail.com>
>> > <mailto:jdh2...@gmail.com <mailto:jdh2...@gmail.com>>> wrote:
>> >
>> >
>> >
>> > On Tue, May 10, 2011 at 12:48 PM, Benjamin Root
>> <ben.r...@ou.edu <mailto:ben.r...@ou.edu>
>> > <mailto:ben.r...@ou.edu <mailto:ben.r...@ou.edu>>> 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
>> 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.
Agreed.
> Second, the overall hierarchy is very inconsistent, with big categories
> ("artists") alongside details ("gridspec").
>
Agreed. I think we can greatly benefit from embracing categories and
other organizational concepts here and elsewhere such as the gallery
and large classes like axes. Are there good markup approaches we can
take to tag some docstrings to help sphinx organize things like this?
However, for the v1.0.x docs, I think the goal should be to get
whatever is missing filled in. Then merge that up to master (and add
animation_api docs). It would be in master where I think structural
changes to the docs should go.
I will have more time available Wednesday to work on this and I also
anticipate doing some of my wishlist work on mplot3d next week.
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
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
