Re: convert-ly rule

[David Kastrup]

David Kastrup <address@hidden> writes:

> "address@hidden" <address@hidden> writes:
>
>> On 13 mars 2013, at 11:56, David Kastrup <address@hidden> wrote:
>>
>>> "address@hidden" <address@hidden> writes:
>>> 
>>>> Then that would mean that the tuplet bracket could never use side
>>>> position interface and vice versa.
>>> 
>>> Yes.  The set of interfaces is not user-changeable as far as I know.  So
>>> this would hamper the system programmers regarding the possible
>>> interface choices rather than the users.
>>> 
>>> Not fabulous, but I have a hard time at the current point of time coming
>>> up with something that does not either have significant naming
>>> redundancy and awkwardness, or is lacking flexibility.  At least when it
>>> is supposed to fit more or less with the current scheme of things.
>>
>> Makes sense.
>>
>> In my work with eliminating the translate_axis call, then, I'd need to
>> create an:
>>
>> outside-staff-interface
>>
>> For all grobs that can be positioned outside the staff.  That way
>> TupletBracket could be part of this without having bleedover from the
>> side-position-interface's use of staff-padding.  It'd require adding a
>> new interface to a lot of grobs, but it actually adds a lot of
>> clarity, as in the documentation we can indicate that the internals
>> reference shows all grobs that can be outside-staff positioned via
>> this interface.
>
> This sounds like a plan.

Ok, so should ly:grob-property get another optional argument that will
only fetch the property (rather than delivering the default optional
argument) when the interface named in the additional optional argument
is part of the grob?  Sounds like a reasonable hook into that kind of
behavior.

-- 
David Kastrup