[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Project - Eliminating grob parents and outside-staff-priority
From: |
address@hidden |
Subject: |
Re: Project - Eliminating grob parents and outside-staff-priority |
Date: |
Sun, 30 Sep 2012 14:57:19 +0200 |
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
- Re: Project - Eliminating grob parents and outside-staff-priority, (continued)
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/29
- Re: Project - Eliminating grob parents and outside-staff-priority, Keith OHara, 2012/09/29
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/29
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, Janek Warchoł, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority,
address@hidden <=
- Re: Project - Eliminating grob parents and outside-staff-priority, David Kastrup, 2012/09/30
- Re: Project - Eliminating grob parents and outside-staff-priority, address@hidden, 2012/09/26
- Re: Project - Eliminating grob parents and outside-staff-priority, Joe Neeman, 2012/09/26