Re: [Denemo-devel] Bookpart command

[Richard Shann]

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: application/xml