Re: [Denemo-devel] staff directive icons and whey they (should) do.

[Richard Shann]

This is a good piece of work which gets the current situation
documented. Reading over this I think that there is, indeed, a design
flaw here, though not the same as your analysis.
On Wed, 2011-01-26 at 15:53 +0100, Nils Gey wrote:
> Current situation if you add a staff (voice?) directive and click on the 
> icon/label:
> 
> 1) If a filename <Tag>.scm is present in editscripts it will be executed
> 2) If there is no filename but a command with the same name as the tag it 
> will be called
> 3) If there is none of these (the tag-command crashes?)
no - it will simply check if a action exists for that name - I was
mistaken in thinking that a script-call could be involved here
>  a click shows the advanced edit menu.
> 
> I think this violates main ideas of Denemos design (see below) and should be 
> changed to:
> 1) On directive creation the user can give scheme code as directive command 
> (d-DirectivePut-staff-script function). function is the normal Scheme way, 
> you either give a defined one or you give (lambda () ... ). 
>   1b) This scheme code is saved in the .denemo file as is and executed if you 
> click the icon.
> 2) If there is no edit-code a click shows the advanced edit menu.
> 
> Note: You may say that the advanced edit window should not be visible to 
> normal users. I don't think we have a problem here:
> a) Under normal circumstances the user never uses a directive which is not 
> provided by Denemo itself (a menu command) or he will create them 
> him/her-self. In the first case there will be no directives left which do not 
> have a edit-script, even if its very basic because I plan to review all 
> directives and remove the redundancy by creating and developing 
> ToggleDirective which will auto-generate a basic edit-script if nothing is 
> specified.
> b) Denemos target user is not considered as dumb. The advanced edit dialog 
> does not offer more options to break something that the normal, always 
> visible, "Insert Lilypond". The advanced edit is also avaiable on right 
> click, which is no big difference.
> c) On the contrary: Giving the user these options he will get a better 
> understanding of how things are named and work.
> 
> Now the reasons why I think the current situation, 1+2, do not match with 
> Denemos philosophy.
> All basic commands, the built-ins, are one-way. Since all other 
> scripts/command are based on these all Denemo commands are one-way.
> They all place an object in the denemo score, which is the .denemo file in 
> the end. This object does not know which command created it, which is a huge 
> benefit:
> I. Backward compatibility is guaranteed. If the command changes the object in 
> the score will not be affected.
> II. You can share .denemo files or move them between different versions and 
> the creation-commands are not needed on the other system/version.
> 
> Both calling the Tag as command and using an edit-script break this
> system.
>  If the command or the edit-script changes or moves to a different name or 
> gets deleted you can't use the staff-icon anymore.
you should be able to use the staff-icon to get at all the
staff-directives in any circumstance. If not that is a bug. The only
circumstance where this should happen at the moment is where you have
a .denemo file generated by a more modern version of Denemo than the one
you are running, or a custom version - the editscript or command may be
missing. This is because we have no "modules" at the moment - everything
- accordion shifts - tablature - drum notation is available to all
commands. We are *not* entitled to delete a command, or even alter the
semantics (except perhaps to extend them); we have to write a new
command and hide the old one. Likewise we are not entitled to delete an
editscript unless we intend that the directives to which it refers shall
henceforth be edited by the other methods.
Obviously at some stage we will want to clear out old crud, and warn
people to update their old files, but that is not germane.

So, I am happy with that. Where I see a design flaw is that there is no
protection against a new command being created whose name clashes with
an established tag. In that circumstance the new command could become
the edit method of a directive that is not expecting it. The mistake I
made was not requiring the creator of the directive to specify
explicitly that the tag is also its edit command - the classic case is
of course toggles. Fortunately, this is fairly easy to fix:
DENEMO_OVERRIDE_EDIT should be set on any directive whose tag is the
name of a command to be used for editing. This change will mean that
existing scripts that use the tag-as-command editing method will need
this override adding.

> The new design, point 1), seems to violate this principle, too, because it 
> possibly makes use of a pre-defined function which can be changed. But its 
> much more unlikely, plus its possible to use (lambda () ... ) to give the 
> complete script and only make use of the most basic commands. (of course we 
> can do nothing about Guile changing its functions :) )
> 
OK, so I don't think we need the new design. But I do have some ideas
about problems with it, and one rather amusing thought which goes right
back to Russel & Whitehead's Principia Mathematica and the work of
Frege.
A problem with including the editscript with the directive is that such
a script would be copied about a lot, and for some directives (e.g.
notehead alteration) could be present thousands of times in a score.
If we want to go in this direction what we could do is to store all the
editscripts that *could* be invoked for the particular score as it is
saved. That is, we would go through the score looking at all the
directives and checking for editscripts that would be invoked, read
those in and store them in the file. This is rather like including the
font info with a .pdf file. Again, it would bulk out the file a bit, but
not to the extent of copying the script at every directive.

The amusing thought is this: consider writing the script to create a
directive with its own edit script, where the script toggles: you get to
the point

(d-DirectivePut-staff-script "mytag" ".....

and at this point you start copying in the script itself, the one you
are writing :)
Of course, you could invoke the script itself by its command name

;;;;MyCommand
...
(d-DirectivePut-staff-script "mytag" "(d-MyCommand)")
...

Which of course requires the command to be present on the system where
the file containing the directive is opened.

The bottom line here though is this: we are talking about *editing* an
already created directive not the operation of commands themselves. When
eventually that 10000's of lilypond commands becomes too great we will
find ourselves opening a file with, say, accordion shifts, and not being
able to edit them without importing the accordion module, but I think
that's ok. We can still print the file and play it.

Richard


> 
> Nils
> 
> _______________________________________________
> Denemo-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/denemo-devel