Re: the "separate, but integrated" website proposal

[John Mandereau]

Le lundi 03 août 2009 à 05:51 -0700, Graham Percival a écrit :
> Well, it depends how you define "tweak".  In the LM, we lean
> pretty heavily on "tweak = \override and \set" (plus others).
> Some of those examples definitely *do* use tweaks!
>
> I'd rather keep the wiggle room and just say "look at these
> examples".  Nobody will think that we loaded the images in gimp
> and changed things!

I meant applying obscure covnersion steps, but they will be difficult to
avoid to obtain in the result.  This makes me remember we should add
links to PDFs.


> I'd also rather keep the safety of *not* generating them for every
> stable release.

GUB comparison tool output-distance is designed to check such changes
before releasing, so it could be used for examples too.


> - for X months, where X is as large as possible, the "stable"
>   branch *is* the "main" branch, so there's more changes.

I agree with this; however, changes that bring regressions should not be
accepted in stable branch but should be the starting point of a
development branch.  If you don't have this policy, then the word
"stable" loses its meaning.


> - the examples will deliberately do fancy stuff; a small change to
>   a spacing algorithm or improved slur shape might result in a
>   manually-placed fingering causing a collision.

Would you allow any regressions in stable releases?  We could also put
output-distance in service for the examples.


> If this wasn't our "pride and joy showcase for non-users", I'd be
> perfectly content letting the images be built however they are.  I
> mean, I don't care (much) if a headword ends up looking silly.
> But on the website, I *really* want to be certain that nothing
> changes unless we explicitly want it to change.

Agreed.  This doesn't mean that they shouldn't be generated.


> It's true that we *could* remove the Download pages.  But again:
> they don't really cause any problems.  The install instructions
> are in there, so theoretically somebody might get lilypond and the
> docs on a CD, but might not figure out how to double-click on the
> lilypond.exe file.

You're right, I forgot this point.


> Hey, there must be *some* reason why the windows users wanted an
> enumerated list of 6 items!  On a more serious note, the info in
> Unix or MacOS X could well be useful.

Sure :-P


> I just meant that in general, it should be easy to change from
> stable/2.x to stable/2.y (or even stable/3.x).  i.e. please add a
>       IMPORT_FROM=stable/2.14
> to the top of the makefile (or python script).

Sure.


> I thought the website was going to be built from the stable
> branch?  If we're doing that, then let's delete the web branches.

This means importing all web stuff into the main source tree.  This is
doable, but the part that will be done by hourly cron job will have to
be well distinct.  This means much buildscripts hacking and janitoring,
but this is OK.


> Why should the 3 logos -- one of which is depecated, and one of
> which I've never seen before in my life -- have their own dir?
> I'm not totally against this, but I can't see a good reason for
> it.  Especially with a generic name like "pictures".  Now, if it
> was "logos", or possibly "old-and-unused-and-current-logos", then
> I'd agree.

I'm lazy about moving directories except with strong justifications.  If
you really want to, I tell you a recipe for next time:

cd Documentation
git mv pictures logos
cd ..
find -name '*.make' -or -name 'GNUmakefile*' |xargs grep pictures

then replace occurences of pictures by logos
(you could even replace grep by "sed -i -e s!pictures!logos!g" then
check the result with git diff).



> Fine with me.  In the comment for the import, please write
> something like
> ----
> Web: import files from web-gop branch.
> 
> Overall structure by Graham, with many comments and suggestions
> from -user.  Patrick McCarty worked extensively on the css and its
> integration with texinfo.  Jonathan worked on the Introduction.
> Patrick Schmidt did further work on the CSS and the Old news page.
> ----

Noted. I'll work on something clean enough from a source files and
directory perspective and push general.texi (sorry, there is a directory
named lilypond/ for Info docs with images build, and I don't want to do
special casing for MANUAL_SUBDIRS) and its inclusions tomorrow if
everything goes well.  There will likely be rough edges in the output,
e.g. if I haven't managed to quickly convert Jan's patch to a usable
init file chunk.


> > I'll hack lilypond-book to produce snippets with preview images
> > and "click to enlarge/click to see the complete score" links.
> 
> ... I'm still really iffy about this.  Both Jonathan and I spent a
> few hours trying to force lilypond to create images with a
> specific pixel width (600 pixels, IIRC -- see
> texinfo/examples/GNUmakefile).  We both failed.

Ugh. Lilypond already resizes in a similar way as what you put in
$(SCALE), why don't you calculate the appropriate -dresolution value?
This is just distance units conversion.  BTW it should use
-danti-alias-factor=2, but we'll get this for free in the main sources
infrastructure.


> I think the above text is sufficient
> to cover attribution.

It think so.

Cheers,
John

signature.asc
Description: Ceci est une partie de message numériquement signée