2015-04-22 21:41 GMT+02:00 Urs Liska <u...@openlilylib.org>: > > > Am 22.04.2015 um 21:29 schrieb Gilles: >> >> Hello. >> >>> I think you could vastly benefit from using openLilyLib's GridLY >>> library. Of course thst's only viable for new projects. >> >> >> That looks interesting just from a quick reading of >> https://github.com/openlilylib/openlilylib/tree/master/ly/gridly >> >> I stumbled upon that page only through a web search... >> >> The "openlilylib" web site refers to github but then it is not >> clear what functionality can be found there and how to install >> and use it (the links of the examples at the bottom of the above >> page point to nowhere). > > > a) > There is a fundamental reorganization of openLilyLib going on at the moment. > The "new" infrastructure, along with _some_ content (the amount of content > that is needed to develop the infrastructure against) is all contained in > the /ly directory. Everything outside is the "old" stuff which is basically > a bunch of loosely-organized snippets. > > b) > When the basics of that reorganizations are sufficiently completed (and one > of the most important points here is the creation of a decent auto-generated > web documentation) all contributors will be asked to help migrating the > existing content to the new structure > > c) > When that is ready the openlilylib.org website will be relaunched, including > references of the libraries in subdomains, such as (not existing yet) > gridly.openlilylib.org. > We'll have to see if that seems "persistent" enough then to be referenced > from the LilyPond documentation. > >> >> Is this something to be included in LilyPond at some point? >> If not, why? > > > The main objective of openLilyLib (old and new) is providing a platform for > extending LilyPond without having to integrate everything in the core. This > is a) because not every extension should bloat the core and b) even when > something would fit well it is often extremely hard to get new functionality > past the doorkeepers ...
I disagree. I don't think it's a problem to get new functionality into LilyPond, _if_ it's coded properly. Sometimes people are scared by a maybe too rough tone, though. Speaking only for me. That never bothered me. I'm only interested in the best possible code. Ofcourse this code should work with _all_ of LilyPonds features and not only with the usecase I had in mind. If some of my ideas (and patches) were rejected because of not best elaborated code, I try to do it better with the next patchset or I have to accept that I don't have the knowledge (or the time to get that knowledge) and stop working on it. How to do it different? Lower our standards? I'd say no! > But in principle openLilyLib can be seen as a development platform for > functionality that may eventually be included into LilyPond. You seem to see this as an advantage. Again, only speaking for me: I don't have the time to look into openLilyLib and/or review what happens there (whereas I'm subscribed to our user-, bug- and devel-mailing-list). All developments made there are lost for me unless I really do search for something. It's simply a matter of time (and energy) on my part. > Examples are > Jan-Peter Voigt's edition-engraver that should definitely become a core part > one day, and (very current example) notation font selection: while working > on that some issues arose that made Abraham and I started developing some > things directly in the LilyPond code base instead of in openLilyLib. We're > right now preparing a patch. > > Urs > > >> >> >> Thanks, >> Gilles Cheers, Harm _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user