Am 20.07.2014 11:10, schrieb Janek Warchoł:
Hi folks,
as you can see, i'm falling behind with lilypond stuff, but i wanted
to let you know that i've skimmed through this discussion and it LGTM.
The only comment i have is: try to make things as simple as possible
(but not simpler, of course) - i wouldn't like openlilylib getting a
"java-smell" from trying to be overly generic and all-encompassing.
Please continue with my blessing ;-)
best,
Janek
I'll try to find a way through the options. I think that when there is
an automatic way to generate the documentation this will encourage
authors to do it right in the first place. Just an example: The
"description" header field will be used in the documentation. And when
one sees this in the HTML docs one will voluntarily take care of having
a good description.
But I'll try to keep the complexity as low as possible.
I think the decision to have a single directory for all include files
was a good one in that respect.
Best
Urs
2014-07-08 12:42 GMT+02:00 Urs Liska <u...@openlilylib.org>:
Am 07.07.2014 16:48, schrieb Paul Morris:
Urs Liska wrote
Hm, I think I_must not_ start with such a script right now, since I
know that this - although being not too complex - will eat up too much
of my time and concentration.
But your message triggered a little bit of thought, and I came to the
conclusion that we should use a website (i.e. openlilylib.org) for the
documentation.
The script will have two stages: parsing the content of the library and
generating documentation from the resulting internal representation. I
think generating complete HTML pages isn't more complicated than
generating Markdown, but the results are better to use: We have more
control over the layout and formatting options than on a Github Wiki,
_and_ we have a self-contained HTML site that can also be deployed
locally.
Yep.
This might be a good opportunity to get my feet wet with PyQt, i.e. not to
write a _script_ but an application. Initially this wouldn't do much more
than a mere script, but with more convenient interactivity. Later it could
add an interface to _edit_ the metadata (e.g. selecting from existing tags,
batch renaming of tags etc.) and also the documentation strings themselves.
And it can even incorporate a convenient documentation browser.
I think we should target the documentation output to be a self-contained
HTML site in the repository itself (in a /doc directory) and only them
consider making it available online too.
At least with the HTML part of such a documentation I'd be glad for
assistance (if I really get this started at all). Not that I'm unable to do
that part but others can do that better, and it's a convenient split-point
to share work.
Best
Urs
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user