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

[Nils Gey]

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


Nils