Re: warnings during `make web'

[Juergen Reuter]

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