Re: [Denemo-devel] Documentation of Scheme interface

[Richard Shann]

On Fri, 2008-10-03 at 17:58 +0100, Richard Shann wrote:
> On Fri, 2008-10-03 at 17:35 +0100, Richard Shann wrote:
> > > cursorclef stores the value of the clef at the current position. 
> > Is it re-calculated every time you click with the mouse, or do
> > CursorRight/Left? 
> This thought has prompted me to look in mousing.c where I remember
> seeing
>       /* Quickly redraw to reset si->cursorclef.  */
> How you can persuade gtk to be quick about it I don't know. I think this
> may be the origin of the bug that I suspect is lurking there: what is
> there to guarantee that gtk is actually going to call the draw routine?
> Some of these bugs may start coming home to roost as we control Denemo
> from scripts - there is no idle time.

I've been looking into this matter of the prevailing clef at a given
point in a measure. There is a function (I think I must have written it
though I don't remember doing it) called find_prevailing_clef() which
finds this: cursorclef is really an internal draw routine variable, but
it is used, as you say, to initialize curmeasureclef whose meaning is
completely obscure to me - it is set in the draw routine (presumably to
the clef prevailing at the start of the measure) and then reset to
cursorclef in commandfuncs.c (presumably to the clef prevailing at the
end of the measure).

I suspect this tangle is due to a worry about efficiency - the draw
routine goes through all the objects in order, and so it was tempting to
try and pick up the prevailing clef (etc) as the draw routine passed
through the current object on its way drawing everything.

So, we need to bear this in mind when writing scripts - use functions to
get the data needed rather than relying on any fields which the draw
routine affects.

Richard