On Tue, 2016-07-12 at 20:52 +0200, Andreas Schneider wrote: > Sorry that I took so long to answer. I was very busy. No hurry!
> > Am 07.07.2016 um 18:37 schrieb Richard Shann: > > On Tue, 2016-07-05 at 21:19 +0200, Andreas Schneider wrote: > >> Am 05.07.2016 um 10:41 schrieb Richard Shann: > >>> On Sun, 2016-07-03 at 20:14 +0200, Andreas Schneider wrote: [...] > > Yes, that is the logical way to have things. Does the attached file give > > the desired output though? It has three chapters the middle one being of > > only one movement. Just done with Book Chapter, (and Score->Simple > > Titles->Title for the singleton chapter). > > No, this is not my desired output because normally each movement has a > title. At the start of a chapter there is first the chapter title > (preferably in a larger font) and then the movement title. Well, but that is only a matter of adding these movement (sub)title fields, with the attached Denemo file I have taken the previous version and edited the chapter titles editing the size of the text and then added movement titles (using the subtitle field - I *think* your "Chapter Title" is using the movement title field). So does it now look like your intended output? > >> For the first movement in a > >> chapter there is first the heading of the chapter and then the heading > >> of the movement, regardless if the given chapter contains one or more > >> movement(s). > >> I am thinking about how one can overcome the restriction that a chapter > >> cannot end at the same movement where it starts. > >> First of all, your > >> solution is clever because it does not need a reference (e.g. to the > >> movement number where the end is) that may void if movements are > >> inserted or deleted, and because it automatically prevents starting a > >> chapter where a chapter end is already present. At the moment you cannot > >> begin and end a chapter at the same movement because you use the same > >> tag for both begin and end. > > > > Well, no actually you *can* have begin and end on the same movement - > > you could have a single Denemo Directive with the tag SimpleChapter but > > with both prefix and postfix fields filled in for the end and start of > > chapter respectively. You could test for this case (you get #f for a > > field that isn't filled in) and write the script to handle that. > > Your idea is more elegant than mine. So this should be the way to go. > > >> When using a different tag, that restriction > >> would not be present any longer. Is there a directive to get the number > >> of movements in a score? > > I don't think so - it is (d-PushPosition)(while (d-NextMovement))(set! > > number-of-movements (d-GetMovement))(d-PopPosition). > >> Maybe I can come up with some code. Or do you > >> think that approach is not wise? > > > > The advantage of using a single tag is that it can be (and is in this > > case) the name of the command, and so the user can re-run the command in > > the Movement Properties Editor. Directives that have a tag that isn't a > > command name are more difficult for the user to work with - Denemo > > doesn't know what command created them and can't give any guidance about > > them. There *is* a mechanism to mitigate this - you can write an > > "editscript" named after the tag and put that in the actions/editscripts > > directory, but I think that is over elaborate. > > I see, I did not think of that. The reason I wouldn't do something so elaborate is that it means the code associated with the command is spread over two files (actions/menus/..../SimpleChapter.scm and actions/editscripts/SimpleChapter.scm), making maintenance more difficult. > > >>>> * If you give an end movement number that is larger than the number of > >>>> movements and thus does not exist, the script does an infinite loop. In > >>>> that case the end movement should be set to the last present movement > >>>> and a warning be given. > >>> > >>> I've fixed this. > >>> > >>>> * If you give an end movement that is before the start movement, the > >>>> lilypond code is erroneous. That should be checked and an error message > >>>> given. For example before line 32: (if (< end (d-GetMovement)) > >>>> (d-InfoDialog "Chapter end cannot be before chapter start!") (begin ... > >>>> )) > >>> > >>> that fix also prevents bad code generation in this case > >> > >> I suggest to give a message to the user in this case, e.g. by inserting > >> (d-WarningDialog (string-append (_ "Invalid movement number: ") end )) > >> as else branch of the (if ...) starting in line 28. > >> > >>>> * The end movement cannot be changed. (This becomes important if one > >>>> insert a movement at the end of a chapter.) If you click on EndChapter, > >>>> you just get an information dialog. It would be more convenient be told > >>>> the movement number where the corresponding start is and given the > >>>> option to move the EndChapter to another movement. Workaround is to > >>>> delete and re-insert. > >>> > >>> Hmm, it seems you have to delete the start as well as the end and the > >>> re-instate. > > > > actually, there should be a cleverer way - you make a button that will > > create a clone of the End Chapter, then delete that End Chapter, move to > > the movement where you want the end to go and use the button to > > reinstate the End Chapter in the new position. > > That sounds like a good possibility. However, it also sounds like a lot > of work for which I don't have the time right now. ??? I think I may not have been clear. What I'm referring to hear is just something you might do in just a moment - you are about to delete the End Chapter and before hitting delete you hit "Make Button for Clone" putting the End Chapter object into a palette. Then hit delete move to another movement and use your palette button to re-instate the End Chapter on the new end movement. You could keep that palette button for future use too, saving one step in future. Richard
ChapterTitles2.denemo
Description: XML document
_______________________________________________ Denemo-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/denemo-devel
