Re: Use arbitrary notes (with stem/flag) as MMR stencil override

[David Kastrup]

Kieren MacMillan <address@hidden> writes:

> Hi David,
>
>> What do you think the presence or absence of some interface implies?
>
> I think the presence of an interface means a shared behaviour is
> implied between grob types which have that interface, the
> implementation of which is individually determined for each grob type.
> For example, I think that all grob types which share the
> text-interface have a baseline-skip property that can be interacted
> with (where hopefully an implementation of that property for that grob
> type has been created, or setting the property will have no effect).

Well, there we have the problem.  Having an interface implies having a
set of properties.  That's all.  It remains the grob's responsibility to
actually do anything with those properties.  An interface often is
associated with a set of available Scheme functions (often carrying the
interface name in their name) but that association is just a convention
without programmatic consequences.

> So in my (possibly deeply flawed) grasp of how interfaces work: a
> measure-centred-interface might add a centre-in-measure property,
> which centres the grob [type] within the current measure; for MMRs
> that would be set to true by default, and for other grob types (e.g.,
> NoteColumn or NoteHead) it might be set to false by
> default. Overriding that property would then engage whatever
> programming was in place to centre the grob.
>
> How far off the mark am I?

An interface may include some property but that does not make a grob do
anything with that property.  Those grobs which you'd desire to heed
that property would all have to be programmatically changed to look at
that property, by employing some interface-specific function in their
internals or similar.

Basically calling for an interface just calls for giving a set of
properties a label.

-- 
David Kastrup