[Top][All Lists]

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

Re: [Denemo-devel] deletescore()

From: Richard Shann
Subject: Re: [Denemo-devel] deletescore()
Date: Thu, 17 Feb 2011 22:08:08 +0000

On Thu, 2011-02-17 at 15:07 -0600, Jeremiah Benham wrote:
> I was looking through the code file.c and I noticed this function
> deletescore on line 1162. importMidi use to call this in order to
> replace the currnent movement. It was effective at doing this. When I
> looked at the code the comments did not match up with what the function
> was actually doing. The comments say that it does this:
> /**
>  * Delete the movements of the given score and create a new one
>  * with one movement and empty music data, no title
>  * This is the action for the d-New command
>  */
> It does NOT delete all the movements. It deletes the current movement
> only. 

It DOES delete all the movements. Its first statement is
free_movements() which is in view.c and that does

 for(g=gui->movements;g;g=g->next) {
    gui->si = g->data;
    gui->si->undo_guard = 1;//no undo as that is per movement
which frees all the movements (by putting them in gui->si and calling
free_score(), this is horribly named free_score() frees the current
movement gui->si, ultimately the name DenemoScore was because LilyPond
called a movement \score {   } and only later realized you could have
more than one and wrapped that in \book { } for the whole score of
several movements.

I would seriously suggest you don't touch this code. There is really no
reason at all to do so, unless you are able to do a *lot* of tidying up,
there are really horrible, intractable problems buried in it.

Instead, return to the code you had where d-ImportX behaves just like
d-Open. Leave everything else to scheme, which can start a new tab (new
DenemoGUI) and import into there, and give a (file)name to it (by
d-Save, or d-SaveAs, which ever is implemented to take the filename=

One thing I didn't mention in the previous email is that in Denemo the
name of a score is the name of the file on disk, nothing more or less.
It would be possible to implement something else, but at the moment that
is what it is. So to give the newly imported score a name requires a
save to file. (And "Untitled" is a magic name, that is, you cannot have
a denemo score whose disk file has that name).


> This is function is called here:
> file.c:      //deletescore (NULL, gui);
> file.c:         deletescore(NULL, gui);
> file.c:      deletescore(NULL, gui);
> file.c:deletescore (GtkWidget * widget, DenemoGUI * gui)
> lyparser.c:   deletescore(NULL, Denemo.gui);
> scoreops.c:      deletescore (NULL, gui);
> scorewizard.c:        deletescore (NULL, gui);
> scorewizard.c:    deletescore (NULL, gui);
> view.c:      // deletescore(NULL, gui);
> So perhaps this function needs to be renamed and/or the comments
> rewritten. 
> The reason I am bringing this up is because in attempt to unify the
> load/import behavior I saw this and then I looked at importXML. This is
> a few things that it calls when opened with REPLACE_SCORE:
> free_movements(gui);
> deleteSchemeText();
> later it calls (if ImportType is REPLACE_SCORE):
> free_score (gui);
> if(gui->movements)
>   g_list_free(gui->movements);/*FIXME free all the other si */
> gui->movements = NULL;
> init_score(gui->si, gui);
> gui->si->currentstaffnum = 0;
> ret =  parseMovement(rootElem, ns, gui, type);
> I want to clean some of this up. Should I rename deletescore or should
> newly imported files use something else when ImportType is
> REPLACE_SCORE. I was considering adding a boolean to the functions
> arguments so that I can toggle force or not. If force then no
> confirmation pop up will occur.  
> Jeremiah
> _______________________________________________
> Denemo-devel mailing list
> address@hidden

reply via email to

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