lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: convert-ly rule


From: David Kastrup
Subject: Re: convert-ly rule
Date: Wed, 13 Mar 2013 11:00:26 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux)

"address@hidden" <address@hidden> writes:

> Hey all,
>
> I'm not too good at writing convert-ly rules.  Is there a model I can
> use for replacing a property with another?  Specifically, I'd like to
> write a patch changing:
>
> TupletBracket.staff-padding
>
> to:
>
> TupletBracket.bracket-staff-padding
>
> as one cannot currently use the side position interface callbacks on
> TupletBrackets because staff-padding in the tuplet-bracket-interface
> works differently than staff-padding in the side-position-interface.
>
> Lemme know if anyone has a good solution.  Otherwise I'll hack away...

I am not happy about name proliferation.  On the other hand, I don't
know how something like

TupletBracket.tuplet-bracket-interface.staff-padding

could sensibly be implemented, and it would be pretty much impossible to
know reliably when and when not a further qualification would be
required to keep all callbacks properly informed.

It might also be possible to let a callback check for the existing grob
interfaces in possible cases of contention and only use the respective
value if the grob had the proper interface.

So you'd have a callback that only looked at staff-padding in the
tuplet-bracking-interface manner if the grob had that interface, and
would look at it in the side-position-interface manner only if the grob
had _that_ interface.

That would require giving grobs a set of interfaces that interpret any
given property only in one manner.

That would work without convert-ly rules and a larger namespace set.  It
would also mean that you would look at the interfaces of a grob in the
documentation to decide which values were supported.  That there are
some callbacks able to interpret the _same_ property differently
depending on the interfaces of a given grob, in contrast, is an
implementation detail buried deep enough to probably not appear
disturbing to a user.

-- 
David Kastrup




reply via email to

[Prev in Thread] Current Thread [Next in Thread]