Re: Project - Eliminating grob parents and outside-staff-priority

[address@hidden]

On 29 sept. 2012, at 18:34, Keith OHara <address@hidden> wrote:

> Han-Wen Nienhuys <hanwenn <at> gmail.com> writes:
> 
>> I think it is a much clearer abstraction to decide that each property
>> can only be evaluated once, and that everything should be driven by
>> callbacks. In fact, one thing I would suggest looking at is removing
>> {before,after}_line_breaking which breaks this model somewhat.
>> 
> 
> Should that apply to properties that describe positioning of objects? 
> Often LilyPond needs tentative positions for objects.
> 
> For example, when setting note-spacing constraints, the separation of staves 
> is 
> taken to be large enough that items do not interfere between staves.  The 
> widths 
> of text items are ignored, based on their extra-spacing-* properties.  Rests 
> avoiding beams have a tentative position.  Some repeated accidentals on tied 
> notes exist, but may disappear.
> 
> The note-spacing code uses skylines, which depend on positions for the 
> enclosed 
> objects, and wants tentative positions appropriate to this phase of layout.
> 

The way you're using "tentative" is almost exactly how pure properties are used 
in LilyPond.  The only example that doesn't work that way is the accidental 
one, which I believe is a bug in LilyPond - I want to say that the space is 
reserved even after the accidental is killed off (I'd have to verify that).

> One way to organize these phases of layout is by registering callbacks to be 
> performed (or maybe in future reset) between phases: 
> before/after-line-breaking. 
> 
> The alternative organizational method in the code today is religious 
> observance: 
> for it is written, On the day of Note-Spacing, thou shalt avert thine eyes 
> from 
> the stems, for stems keep the company of beams, and beams are impure, thus to 
> seek knowledge of the tip of a stem would be impure.
> 
> 

I am a fan of the second over the first.  I think all property look-ups should 
be pure until one is absolutely certain that the property won't change, at 
which point the unpure value should be cached and returned for both pure and 
unpure queries (impure sounds too religious, thus unpure).  The pure properties 
need not always return the same value - they can get closer and closer to the 
unpure as more and more information gets determined.  Cached pure values for 
Items can be flushed at any point if someone wants a potentially better 
approximation, at which point the calculation would be redone and the cache 
restocked.

Cheers,
MS