[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: |
Thu, 5 Oct 2006 08:27:39 +0200 |
User-agent: |
KMail/1.9.1 |
On Wednesday 04 October 2006 13:53, Han-Wen Nienhuys wrote:
> Erik Sandberg schreef:
> > OK. Should I try to do the same for created grobs, too? It shouldn't be
> > that difficult, just add some code to the make_item macro, which
> > registers an init function that adds the symbol to a list. There will be
> > problems with a few engravers (piano-pedal and system-start-delimiter),
> > but those should be solvable.
>
> Hi,
>
> I had a brief thought over this. It would be possible to do this, by
> changing the mechanics of creating grobs. Rather than doing
>
> clef = make_item("Clef", cause)
>
> we should use C++ function that have a similar mechanism to listners and
> acknowledgers, ie.
>
>
> DECLARE_CREATOR(clef);
>
>
> ..
>
> clef = make_clef (cause);
> ..
>
> using some layers, make_clef will call
>
> Grob *
> Clef_engraver::create_clef (SCM cause)
> {
> return make_item ("Clef", cause);
> }
>
> Of course, this is the standard, default case, which would be
> done with a IMPLEMENT_DEFAULT_CREATOR() macro.
>
> However, if we have this, it would be feasible to register/override
> Scheme functions for creation, eg.
>
> \set Staff.clefEngraverClefCreator =
> #(lambda (context cause . other_args)
> (let*
> ((c (ly:context-make-grob context 'Clef)))
>
> (ly:grob-set-property! c 'cause cause)
> c))
>
> this would make it possible to softcode loads of functionality, in terms
> of connecting grobs and setting grob properties.
This sounds very cool; I can look into it after 2.10 if you like.
--
Erik