lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Is GridLY the future? (Was: Do we really offer the future?)


From: Thomas Morley
Subject: Re: Is GridLY the future? (Was: Do we really offer the future?)
Date: Wed, 22 Apr 2015 22:58:01 +0200

2015-04-22 21:41 GMT+02:00 Urs Liska <address@hidden>:
>
>
> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]