On 4/18/09 5:54 PM, "Neil Puttock" <n.putt...@gmail.com> wrote:
> 2009/4/15 Carl D. Sorensen <c_soren...@byu.edu>:
>
>> So why can't we define an AutoBeamPlaceHolder grob description (defined in
>> scm/define-grobs.scm), which has an auto-beam-setting-interface (defined in
>> scm/define-grob-interfaces.scm)? It would have no engraver, but I can't see
>> that having an engraver is necessary for having a grob description. And, at
>> least as far as I can determine, the things that are altered by \override
>> are special context properties called "element descriptions". I'm not aware
>> of any requirement that all descriptions have to have engravers.
>
> How will the engraver access the properties from this grob
> description? AFAIK, the overloaded methods get_property () and
> set_property () must have a pointer to a grob which has been created
> in an engraver, whereas the context property versions can be called
> implicitly (but then they are more limited when it comes to evaluation
> since you have to use an explicit scm_call_* for procedures).
I haven't checked yet for beam subdividing (I will need to, I know), but for
autobeaming, the work is done in a scheme callback, where the context is
available. Already the autobeam rules are called as context properties. It
will be no problem to get them from a context description property in the
autobeam callback.
Carl
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
