[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Denemo-devel] Transpose applied to Selection

From: Richard Shann
Subject: Re: [Denemo-devel] Transpose applied to Selection
Date: Thu, 04 Dec 2008 16:35:02 +0000

I have introduced the new calling convention, as described here.
There may be broken scripts (though I guess not), but it will be better
to take the pain now.

On Thu, 2008-12-04 at 08:00 +0000, Richard Shann wrote:
> On Mon, 2008-12-01 at 19:09 +0000, Richard Shann wrote:
> > I have succeeded in executing the following script to transpose the
> > selection by a major third:
> > 
> > (define Transpose::Interactive #f)
> > (define Transpose::Interval "c e")
> > (ApplyToSelection "d-TransposeNotes")
> > 
> > where d-TransposeNotes is broadly Jeremiah's real_transpositionx.scm
> > which just transposes the current note if not interactive. It turned
> > out
> > that there was no provision for scripts to call scripts, so I have
> > done
> > the plumbing for this and checked it in. It will be a while before I
> > can
> > check in these scripts, as the ApplyToSelection function needs
> > extracting and putting in the init.denemo file (I think). But it
> > works. 
> I have looked at the task of using a script like transpose with scripts
> like ApplyToSelection, and this has prompted some re-think about the
> structure of the interface between Scheme and Denemo.
> At present scripts can pass a string to a Denemo command; this is so
> that the script can supply the responses which a user would give to any
> dialog that the command might invoke. This is fine, but I think we
> should have a cleaner looking return value: at the moment the commands
> return the string, possibly modified, to the script. This is extremely
> flexible, of course, but ugly since you have to start agreeing a set of
> messages (in English) and over-the-top as all we need is a return
> boolean (either it did it, or it didn't). (We *could* return a status,
> but I think that we are better leaving that out: for the rare cases
> where we want to know more about failure we can implement an additional
> query function that does the action and returns a desired type of
> information; by contrast, returning a status already implies creating
> some shared table of meanings which has to be maintained and documented
> and looked up by the script writer.)
> So I propose to introduce a DenemoScriptParameter structure that has a
> GString *input_string and gboolean return_value, and then in a script we
> can test things like
> (if (d-GoToMark)
>       (action now that the cursor is at the start of the selection)
>         (what to do if there is no selection so that goto_mark failed))
> Richard
> _______________________________________________
> Denemo-devel mailing list
> address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]