[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Translator todos
From: |
Erik Sandberg |
Subject: |
Re: Translator todos |
Date: |
Mon, 16 Oct 2006 23:41:12 +0200 |
User-agent: |
KMail/1.9.1 |
On Wednesday 27 September 2006 22:05, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > Hi,
> >
> > Here's a summary of my plans for the translator (I assume all of this
> > will happen after 2.10):
> >
> > 1) separate context-def into two parts, translator information and tree
> > information. Basically, the info shared by engraver-init and
> > performer-init should belong to the 'tree information', which tells us
> > the relationships between context types, while the stuff specific for
> > layout and midi, such as translators and grob properties, should belong
> > to the 'translator' part. 2) remove recurse_over_translator and friends,
> > replace with a dispatcher system. This will probably be a slowdown, but
> > not in terms of O. 3) softcode \consists, \remove as music functions.
> > With the new event system, it shouldn't be difficult to add/remove
> > translators on the fly. Depends slightly on (2).
> > 4) remove Context::implementation. This member is currently only used by
> > translator groups, to search for parents and children. Once (2) is done,
> > it's sufficient to add a parent pointer to each translator group.
> >
>
> This all sounds very good. Of course (3) implies that we'll be able to
> run functions inside \translator definitions as well. I have the feeling
> that this might be a can of syntactic worms. To address that I think
> that it is better to do (1) before (3), because we can do (1) without
> user-visible changes, i.e. we don't paint ourselves into backward
> compatibility corners, while we gain understanding of how to do (3).
I have a clearer plan for context defs now: We could represent each context
def as a Context object, which is used as a template for new contexts. E.g.,
the Voice context_def in engraver-init.ly defines a Context object with
various engravers and properties in it, and when a new Voice is created
during interpretation, the template voice is clone()d, and linked into the
context tree.
This requires a good mechanism for context cloning, which preserves
translators and context properties. This can be achieved using signals, much
like the AnnounceNewContext mechanism: Context::clone sends a CloneContext
event, containing a reference to the newly created context. When the
translator group hears this event, it clones itself and all translators, and
connects the clones to the new context (this should be sufficient to preserve
\consists etc.)
This suggestion does still not make clear how to separate translator-specific
and context-hierarchy-specific information, but we can wait with that
separation.
Plan:
- create a Context::clone, which copies nothing.
- replace lots of references to Context_def with references to a Context which
references that context_def.
- add hooks for translator groups (CloneContext event)
- incrementally stuff out from context def to context and translator group.
This includes the commands \consists, \remove, \type,\override, \revert, \set
and \tempo.
--
Erik