Hey all, I've almost finished moving my vector-graphic package into a module that is usable by invoking one \include statement (it is in scheme code and .so files importable by guile). I decided to do this because the generation of vector graphics readable by my code uses too much kludgery to really deserve to be part of lilypond (currently, I can only really work with Inkscape-generated eps files). Plus, it makes dependencies a non-issue. In doing this, I've realized that almost everything in Lilypond can be made modular, which is a testament to how well it is put together. David had suggested modularity as an option before (perhaps others as well), and there was a brief flurry of support for this idea: I'd now like to re-echo it and work seriously on it to make it part of 2.14. To me, it seems like the following things would need to be done:
1) A folder would be created in (ie PATH/lilypond/2.X.X/module) in which all modules hung out so that Lilypond knew to look there. Each module would have its own folder and could be internally organized however one fancies. 2) A document would be created that invoked all modules that were perma-invoked. That is, any module should be able to be called in a given document, but if the user wants certain modules to be called all the time, this document should do it. Ideally, the document would be nothing more than a series of \include statements. It would have to have a standard path that would not get overwritten from version to version (which would likely involve some copying and pasting combined with some simlinkery). 3) Certain current features of lilypond would need to be modularized. This is probably the most difficult call, as it brings up the question "what should be part of non-modular lilypond"? There are certain things, such as notes, dynamics, and slurs that seem like they should be in any typesetter, whereas woodwind fingering charts, fretboard diagrams, and harp pedals seem more modularish. Of course, the latter things could be shipped with lilypond and even included as a sort of "automatic module" to make for backwards compatibility (ie the user would have to decide to delete them from the document in #2 instead of include them), but I think it'd be important to modularize as much as possible. This is likely very easy to set up and test, but as it seems like a not-insignificant move, I'd want to see first if there is community support and if there is a group of people willing to iron out how this change could be orchestrated. Cheers, Mike P.S. In an unrelated note, many thanks to Patrick for his work on the path command, which will any day now replace the connected-shape stencil - I just tested a new patch of his and it works perfectly. P.P.S. It could be that such a modular system already exists and I am simply not privy to it, in which case I'd appreciate any feedback! _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel