Am 19. Oktober 2019 12:27:07 MESZ schrieb Thomas Morley
<thomasmorle...@gmail.com>:
>Am Sa., 19. Okt. 2019 um 06:58 Uhr schrieb Andrew Bernard
><andrew.bern...@gmail.com>:
>>
>> That's funny - it's the argument I always use for my new complexity
>work, but it usually gets shouted down quite vocally (refer for example
>to my requirement for equal width bars!).
>
>Nah, it's not shouted down. ;)
>Though, there are two points to consider, imho
>(1) I don't understand how equal width bars should work at all, p.e. {
>\repeat unfold 32 b32 b1 }
>(2) I've no clue how it could be implemented.
>
>Looks like it's not only me...
>
>> Anyway, that's why I offered to put in in openlilylib, there for all
>to use if desired.
>>
>> Maybe what we really need is a section on the NR on how to use
>openlilylib, because people seem to find it difficult (which I find
>puzzling, but everybody's experience with computers is of different
>degree). There's precedent for that, almost. We have a section on using
>lilypond with external programs like editors. That would also have the
>effect of bringing opnelilylib more into the core consciousness, rather
>than being an orphan stepchild as it is viewed now, I think.
>
>Well, I have to admit I stumbled across "how am I supposed to use it"
>as well. Mostly because I overlooked the Wiki-button, where all is
>explained...
>Furthermore openlilylib provides an own infrastructure, it is
>_designed_ to use it as a whole library.
>This is boon and bane at the same time, making it impossible to simply
>copy/paste some code (unlike LSR).
Yes, and it was explicitly designed that way because *we* (that was Janek and I
at the time) were uncomfortsble with the effort and code duplication of using
LSR snippets.
It's fair to want to use both approaches, and it's fair to prefer the LSR
approach - but that's how OLL has been conceived, and we won't change that.
>I think many people like the design as a git-based library with the
>current infrastructure.
>Though it has disadvantages as well. The problem with copy/paste short
>snippets I already mentioned. Furthermore one can't share ly-code
>between people relying on openlilylib-functionality and those not
>having installed openlilylib at all.
>
No, I don't think that's a generally valid point. MuseScore does not allow
alternative fonts with exactly that argument.
If you want to create easily-shareable files then just don't use openLilyLib.
But then you must not use private libraries either.
I'm absolutely sure the benefits far outweigh the "cost" in this regard.
, these are my own thoughts about >Wellopenlilylib.
>Furthermore github is nowadays owned by microsoft. I don't think it is
>appropriate for GNU software to point to such site.
>
Ok, then we should drop endorsing Frescobaldi as well. And stop provding
Windows and Mac installers.
But seriously, I don't think penalizing a project for its *hosting* is
appropriate. Besides, Github is (AFAICT) Free Software, and I don't see the
grounds to boycott it based on the company it owns
>I may be wrong here, if I'm wrong we _should_ document how to use it.
The point that IMO speaks against documenting OLL in LilyPond's docs is that it
still isn't in a reasonably "publishable" state. It would be *really* good,
though, to start a community endeavor creating a proper documentation strategy
and a website for openLilyLib.
Urs
>
>My 2 cts,
> Harm
>
>_______________________________________________
>lilypond-user mailing list
>lilypond-user@gnu.org
>https://lists.gnu.org/mailman/listinfo/lilypond-user
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
_______________________________________________
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
