On 8/31/07, Graham Percival <[EMAIL PROTECTED]> wrote:
> Valentin Villenave wrote:
> > 2007/8/31, Graham Percival <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>:
> >
> > > The *only* reason that the regtests are still on the main doc page is
> > > that it gives us a nice set of 3 4x4 blocks of items. If I wasn't so
> > > fussy (obsessive? :) about presentation, I'd remove it from that page in
> > > an instant.
> >
> > ahahaha :)
> > I wondered why the link was still here...
> > For what it's worth, I often say to myself that the Bibligraphy link
> > is not mandatory.
> > Besides, it would be nice if the Program usage was aligned with the
> > User manual.
> > What about the following presentation?
> It's certainly tempting. We'd need to move the current "Bibliography"
> info into Appendix A "Literature List" (I don't know why they're
> separate, anyway).
>
> Anybody else have thoughts about this?
I like it; smaller (on the frontpage) is better. And the bib can
certainly be shoved into an appendix (though it's a very interesting
read every couple of months).
While we're on it, can I ask whether anyone else would like to see the
program reference (NOT the frontpage) flattened out? Ie, instead of
these five categories ...
* Music definitions: Definition of the input data structures.
* Translation: From music to layout.
* Backend: Reference for the layout engine.
* Scheme functions: Primitive functions exported by LilyPond.
* Indexes
... could we have this?
* Music expressions: Objects that represent music.
* Music classes
* Music properties: All music properties, including descriptions.
* Contexts: Complete descriptions of all contexts.
* Engravers: All separate engravers.
* Tunable context properties: All tunable context properties.
* Internal context properties: All internal context properties.
* All layout objects: Description and defaults for all graphical
objects (grobs).
* Graphical Object Interfaces: Building blocks of graphical objects.
* User backend properties: All tunable properties in a big list.
* Internal backend properties: All internal layout properties in a
big list.
* Scheme functions: Primitive functions exported by LilyPond.
* Indexes
The reason I ask is that I've always found the top-level distinction
between "Translation" and "Backend" to be extraordinarily confusing.
This may very well be just me. But easily 90% of my usage of the
program reference is to click on a grob and see what interfaces the
grob supports. To do this I click Program Reference > Translation >
Contexts > [realize I have the wrong list] > Back > Back > Backend >
All layout Objects > [whichever grob]. I may be the only who makes
this mistake but it just seems odd to me that I would keep making the
mistake for going on two years now if we just put a label for "All
layout objects" front an center (like above), thus privileging the
inspect-grob-doc use case.
Anyone else make this mistake? Or do I just need to make better use of
Camino's bookmarks? ;-)
--
Trevor Bača
[EMAIL PROTECTED]
_______________________________________________
lilypond-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/lilypond-devel
