lilypond-user
[Top][All Lists]
Advanced

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

Re: openLilyLib


From: Urs Liska
Subject: Re: openLilyLib
Date: Wed, 27 Jun 2018 15:30:13 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0



Am 27.06.2018 um 14:16 schrieb Jan-Peter Voigt:
Hi Urs, Aaron,

Am 27.06.2018 um 08:35 schrieb Urs Liska:
Hi Aaron,

thank you for the interest in openLilyLib.


> ...
>
pre-alpha state, which does explain things.

Unfortunately this is true, and basically because the project didn't really gain traction. Progress is usually been made when someone has a reason to contribute something, usually a package or some functionality for a package. In many cases that someone is me, but there are a few major contributors to different packages.
Wait a second ... oll-core with its package management is working very well so what are the issues preventing from naming the core a RC? or at least beta?

Essentially the lack of documentation.

The great thing about it is that anything is modularized so any package or module that is not in that state should be marked alpha. But the core? AFAICS a desired feature list naming all the core elements already available is missing to name it beta. Then a testing phase would make it a RC and then stable.

What is missing is a "community" with the intent of bringing openLilyLib into a more generally usable state. Which is a pity because I'm convinced it is a very useful toolkit worth of being more widely known and used.
I believe it very important to name it something more then pre-alpha. I know Its a bit funny if I say so, because I didn't promote my work that way ... but! Few people want to be beta-tester so it should be called "use it! here's how to install"

I would have done that for ages if there were a proper installation manual and overview documents for the different packages.

Right now I'm writing a manual for the package I've started to write, but I'm not fully sure yet if that's the right way forward. I'm writing in Markdown and use Pandoc (with lyluatex) to produce a PDF from it. One thing I'm missing is a proper way to generate an HTML site from that (for example to have online documentation on openlilylib.org) -- which Pandoc should in principle support. The other issue is that this is totally independent from the actual code, so anything (and especially any updates) has to be documented *manually*. Which seems risky to me, since there is no formal review process in place like with LilyPond that makes it less likely to add functionality without documentation.


Documentation would be a good start with this - unfortunately at the same time a vital goal, a vicious circle ...
+1

> ...

The newer one is the "package" system, which essentially means that after \include "oll-core/package.ily" further package and/or modules can be loaded through \loadPackage and \loadModule. (BTW: this ensures that modules are parsed only once ...This is IMO a very usable infrastructure. The thing is that installing a
package means `git clone https://<package-uri>`. That is easy if you are familiar with git, but it may disturb users that are not. So a package-manager that installs packages would be great thing to help those who are not familiar with git. But this is for now just an idea.

Actually Sharon Rosner has written such a package manager. But for some irrational reason I haven't followed up on that, maybe because he decided to add yet another language (Ruby) to the ecosystem, maybe because (IIUC) that requires adapting an OLL package to the package manager. But what that project promised (and kept?) to solve is handling transitive version dependencies (i.e. when package A depends on package B >= 0.6 load that package version, and at least determine impossible cross-dependencies).

Another idea I had already started on is adding openLilyLib support to Frescobaldi. As a first step I wanted to have a tool that shows all available package and their metadata, then I wanted to be able to download and install packages. Once all that would be in place there would be the basis to add user interface elements, the first and foremost being an annotation browser/editor so you can click on an item and enter an annotation right through a pop-up dialog.

I'm not really sure about that whole project since Wilbert (rightfully) wants to keep Frescobaldi focused on its core concerns (editing LilyPond input files), and supporting stuff that requires external libraries is somewhat detrimental to that idea. OTOH I think that there are many things that Frescobaldi could actually use as editing features (for example: switching between different sets of line/page breaks), and it would be comparably simple to make such functionality only available when openLilyLib is "installed". Well, I don't have the time to go further on that so for now this question isn't really one ...

Best
Urs


What services does oll-core provide to packages/modules?  Basically, if I were to come up with an idea for an extension to LilyPond, how would I best evaluate whether openLilyLib would make a good platform on which to build and how would I go about integrating it?

...

The edition-engraver is an extremely powerful tool and we can't thank Jan-Peter enough for having provided it. But the openLilyLib structure makes it possible to create new packages that *use* the edition-engraver and provide very simple interfaces for tools that would otherwise have to be handled in rather complex manner if you'd directly use the edition-engraver. The page-layout.conditional-breaks module is a good example for this.
Thank you Urs! It would still reside in my own cosmos and wouldn't be available without your package manager!

Jan-Peter





_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user




reply via email to

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