[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