On 4/14/09 2:19 PM, "Neil Puttock" <n.putt...@gmail.com> wrote:
> 2009/4/14 Carl D. Sorensen <c_soren...@byu.edu>:
>>
>>
>>
>> On 4/14/09 1:39 AM, "Mats Bengtsson" <mats.bengts...@ee.kth.se> wrote:
>>
>>> Have you forgot about the most basic difference between a context
>>> property and a grob property?
>>> All grob property are connected to a specific graphical object, so the
>>> syntax is
>>> \override Object #'propertyname = ...
>>> In this case, there is no graphical object involved, right? Therefore,
>>> it's naturally a context property, to be set using \set.
>>>
>>> /Mats
>>
>> If I read the code properly (I haven't yet implemented it, so I'm not
>> 100% positive), AutoBeamSetting could be the object, and #'propertyname
>> would be #'(end 4 4). There is code in lily/lily-guile.cc that allows this
>> usage.
>
> I can't see how this would work at all, unless it remains a context property.
Yes, it would be a context property.
>
> In order to be a grob (even an abstract one which doesn't itself
> represent graphical elements) AutoBeamSetting would have to be created
> by an engraver; how would that work, considering that the
> Auto_beam_engraver must know where to stop and start beams *before*
> the beaming grobs are created? You 're effectively suggesting a grob
> which will rework spanner bounds after they've been created. You can
> do this post-processing for things like noteheads and accidentals (in
> NoteCollision and AccidentalPlacement) , since all that happens is
> repositioning of fixed-width items (i.e. Item, not Spanner, grobs).
>
> Property names can be nested, but you can't have what looks like an
> alist handle as a property.
Why not?
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
