Re: Set indent based on instrument name (issue 6457049)

[address@hidden]

On 4 août 2012, at 09:28, address@hidden wrote:

> On 2012/08/01 06:45:22, MikeSol wrote:
> 
>> Avoid measuring extents when engraving is happening because they could
> be
>> dependent on other callbacks which could trigger many layout decisions
> before
>> engraving is finished.
> 
> 
> This is a case where measuring extents early seems appropriate.
> 
> Phil wants the line-indents, thus line-lengths, thus some very early
> layout decisions, to depend on the extents of the instrument names.
> 
> The dependency is reversed in this case from the more usual situations
> where Mike's suggestion holds, such as the extent of a hairpin, which
> depends on the layout.
> 

I agree that the calculation will happen early (definitely before line 
breaking), but if someone writes an exotic callback for the stencil function of 
instrument name that somehow is linked to other grobs, it should only be called 
after engraving is done.

>> Here, what I would do is use the Pointer_group_interface to add two
> grob arrays
> 
> Running through those arrays and re-checking the lengths of the
> instrument names every time we look up the line-indent, would let the
> line-breaker see if those lengths changed for some reason depending on
> the evolving layout.  I do not expect the line-breaker to behave
> sensibly if the indents change like this.

I didn't express myself clearly.  I meant that there should be a finalize 
method in the engraver that loops through the vectors and adds them to a grob 
array via Pointer_group_interface::add_grob.  finalize is only ever called once 
for a given engraver.

> 
>> Properties, in LilyPond, are the best way to stash
>> information.
> 
> Phil, working with properties, or in this case Scheme variables
> associated with layout, does seems necessary.  See set_variable().
> Old scores where we chose \paper {indent = 2.3\cm } to fit the
> instrument names should continue to work.
> If you can figure out enough Scheme to have LilyPond initialize indent
> so that it evaluates a different Scheme variable (say, default-indent)
> and have the engraver updates that variable, then we can have
> automatically-adapting intends by default, and let users override by
> replacing the link to default-indent with their own choice.
> 
> http://codereview.appspot.com/6457049/

I agree that users should be able to override something, but they should be 
able to override a property of InstrumentName or System (depending on how 
things are implemented).
I'm always wary of Scheme variables because of global scopes and multiple 
scores: that has come to bite me in the past.  I generally steer clear of this 
approach and try to make things grob-centric (or if necessary prob-centric).  
There are some things that fall outside the scope of grob-related issues (like 
the paper bloc) but I think it's best to try to use grobs, callbacks, and 
properties as much as possible.  I'm definitely not saying that your solution 
won't work, but I think that going down the grob road is more architecturally 
sound.  Of course, if Phil has time, he can investigate the plausibility of 
both :-)

Cheers,
MS