On 13 mars 2013, at 11:56, David Kastrup <d...@gnu.org> wrote: > "m...@mikesolomon.org" <m...@mikesolomon.org> writes: > >> On 13 mars 2013, at 11:00, David Kastrup <d...@gnu.org> wrote: >> >>> 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. >> >> 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. Cheers, MS _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
