Re: [Denemo-devel] Bookpart command

[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:
> >> Thank you for creating an advanced version of the command. In most cases
> >> it works really well.
> >>
> >> There are a few small things I noticed:
> >> * If you put the end at the same movement as the beginning it does not
> >> work. (A chapter with only one movement may sometimes be needed.)
> > 
> > If I understand correctly there is no need for this, you just leave that
> > movement alone, giving it a title. It makes the single-movement book a
> > bit irregular but was easier to deal with.
> 
> For me, chapters group movements of a special type. Sometimes there may
> be only one movement of a certain type.

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).

>  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.

>  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.
> 
> >> * 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.

Richard


>  At a minimum it should give the opportunity to move the end
> > book part on to the following movement. Bug report? And the command is
> > putting buttons onto the Titles etc button bar which aren't getting
> > removed, this is to do with the overrides set.
>

ChapterTitles.denemo
Description: application/xml