On Mon, 6 Nov 2006, Han-Wen Nienhuys wrote:
Juergen Reuter escreveu:
One theoretical solution would be to introduce a new "ligatureheads.cc"
file instead of using the "noteheads.cc" functionality. However, it turned
out that almost all of the functionality of noteheads.cc would
have to be cloned. Even worse, some other parts of lily call methods in
noteheads.cc (at least in earlier versions of lily they did; I have not
This might have been true when you added this stuff (~ 4 years ago, I think),
but nowadays, note-head.cc has 7 routines, of which 3 aren't used anywhere
else. For good measure, I just removed Note_head::get_balltype() as well.
The other routines have to do with stem attachments, which aren't applicable
to ligatures anyway.
Ok, I will eventually check. (BTW, I suspect there are a bunches of
unused #include's that could be removed...)
The easiest solution that I can see is to tolerate little polution of
"noteheads.cc" and just add the missing interface declaration at the end of
this file. However, that's not my decision...
I think that this is going about the problem in the wrong way. Given how much
lily has changed over the years, the proper solution IMO is to redo the
ligature stuff completely.
Mmmh, but how? Given, that things have changed, as you state, do you
think there should be a completely new "ligatureheads.cc"? If so, should
I clone the print and internal_print methods or rather try to create a
subclass? I think a ligature primitive _is_ a special note head, so
modeling it as a subclass does not sound bad, even if stems are not used.
IF my hunches are correct, most of the code will
collapse and disappear because of improvements in the rest of LilyPond.
I don't think so. Most of the code is about matching grobs and moving
them from different paper columns into a single one, determining the
correct glyph for each notehead by evaluating local and neighbour heads'
properties, adding new grobs (such as vertical lines) in the right place,
collecting dots from different heads in different paper columns and moving
them into a single dot column (I am already using DotColumn!), etc.
I do not see any similar code elsewhere, so I am confident that the code
would not remarkably collapse.
Greetings,
Juergen
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
