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
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
