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. 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. Regards, Neil _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
