[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Denemo-devel] staff directive icons and whey they (should) do.
From: |
Nils Gey |
Subject: |
[Denemo-devel] staff directive icons and whey they (should) do. |
Date: |
Wed, 26 Jan 2011 15:53:02 +0100 |
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
- [Denemo-devel] staff directive icons and whey they (should) do.,
Nils Gey <=