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

[address@hidden]

On 30 sept. 2012, at 14:29, David Kastrup <address@hidden> wrote:

> "address@hidden" <address@hidden> writes:
> 
>> On 30 sept. 2012, at 14:16, Janek Warchoł <address@hidden> wrote:
>> 
>>> Hi,
>>> 
>>> interesting discussion, i learn a lot.
>>> 
>>> On Sun, Sep 30, 2012 at 11:39 AM, David Kastrup <address@hidden> wrote:
>>>> Basically, a grob says "I want to have this and that information for
>>>> making my positioning" and LilyPond says "You can't get it right now".
>>>> Then the grob says "ok, I'll do a tentative positioning", and LilyPond
>>>> will come back with more information later and ask again.
>> 
>> Just to clarify things for anyone following the thread: this is not
>> currently how LilyPond works, but I'm assuming what you're proposing
>> is a suggestion for a model.
>> 
>> It's an interesting idea for grobs to ping a sort of central hive
>> ("LilyPond" in your text above) to know what information they can
>> access and when.  This'd require a major change to the architecture -
>> currently, grobs specify in their request whether they want tentative
>> or permanent information via the use of functions like
>> Grob::pure_relative_y_coordinate versus Grob::relative_coordinate.
>> I'm worried about having a sort of centralized brain that tells grobs
>> what they can and can't know - sounds Kafka-esque.  I like the
>> decentralized model where grobs, via their callbacks, self-police for
>> what information they need from other grobs and when it's ok to get
>> it.
> 
> I have my doubts that you can do a sensible circular dependency
> resolution strategy in a purely local manner.  In fact, the current
> pure/unpure distinction is based on before/after linebreaking, a
> centralized operation.
> 

It is true that line-breaking is a centralized option based on what the 
toplevel-book-handler is, but it should be as lightweight as possible.  I think 
that the smaller we can keep paper-book.cc and paper-score.cc, the better.  
I've been saying this for a couple years, but I'd prefer for Book and 
PaperScore to be grobs so that even they could use the callback model.  At that 
point, line breaking could just be controlled by callbacks.  This would also 
pave the way for better Prob / Grob integration - it is currently difficult to 
get toplevel markups and systems to play nicely because they are outside of 
this callback model.

The current pure/unpure distinction is based on what people ask for and when.  
Pure offsets and extents are used until the dim_cache_ is filled, at which 
point real offsets and extents are used.  As a convention this is before and 
after line breaking, but there are places where pure properties are requested 
after linebreaking and non-pure properties are requested before.

Cheers,
MS