Re: [Denemo-devel] Current state and plans

[Richard Shann]

On Sun, 2008-11-23 at 17:25 +0100, Nils Gey wrote:
> Hi,
> 
> I lost a bit where Denemo stands now and what is work in progress.
> 
> Currently I see most work done on midi-import where two ways are implemented: 

> One JACK-midi and one direct access. 

> Maybe you can inform me (and others) why this dual system benefits the users?
The direct access if for those (like my Debian Etch) that don't have
jack-midi. I hope this can be dropped in the future.
> 
> Then all the time there are new scripts and functions which is really great. 

> Will these scripts be bundeld with new releases?
I think we will put them all in the release, especially as we have no
"More from Denemo.org" option (which I think the gio library makes
possible).
>  If Denemo gets more users and user scripts can we integrate a 

> system to easily download new scripts from the web in the (far away) future? 
It is not the far-away future. I could have it done tomorrow, but it is
not a high priority, as at the next release all the scripts available
will be in the release itself. But as soon as releases become less
frequent, and new scripts at Denemo.org become available we will want
Denemo to have the "More from Denemo.org" option.

> Note: When the time comes where users actually want to submit scripts we (I) 
> should be ready to give

>  them a central place to store them and also we should review 
Yes: review will be important - you could easily write a scheme script
to delete the user's home directory or some other malicious activity.
> what scripts will show up so that we can include

>  the better ones right into the Denemo releases.

>  There a plentyful linux applications where the real deal is made with 
> scripts (for example IRC clients

>  and where it is a pain to get the real good ones, integrate them to your 
> software 

> and know any time which scripts work with the current version)
Yes, there could be a lot of housekeeping needed.
> 
> What I see a bit ambivalent is that all these new features and scripts are 
> not featured enough.

>  The "more commands" file browser
There are two, for commands (actions) in the release (under
$prefix/share/denemo/actions/menus
and one for commands you have written yourself (under
~/.denemo/actions/menus).
>  is a bit confusing because you have to scroll through your filesystem
This is better than scrolling through a list of all commands: the
filesystem is laid out to match the menu system, so that the menu names
classify the commands.
In the future we could run a script to list all the commands with
tooltips and with parameters needed for calling from scheme, inserting
this into the manual. 
>  and you get not enough infos what these things are.
In the future we would like the file selector to have an extra pane in
which the tooltip of the selected command is displayed...
Again, this is not rocket-science - on getting the selected signal you
run the parser extract to tooltip and display it.

>  Especially when there will be more and more scripts this could be some issue 
> for the users. A script-management dialog (like other programs have "plugin 
> browsers") would be a great benefit. I'm just giving out ideas, I know there 
> is much work to do which is more important. 
> 
> Did I forgot anything?
> 
> What is also a bit ambivalent (in my opinion) is that there are more and more 
> features

>  which are just shown as little green lilypond-"lines". What is needed to 
> make more functions "real" Denemo objects 
I have a cleverer plan than that. Instead of making more and more "real"
Denemo objects, (which involves creating more C-structures and writing C
code to create/destroy/cut/paste/draw/store/load/print them,  we just
make the lilypond objects more sophisticated. I have written about this
earlier: I have also started implementing this, if you create a LilyPond
directive you get ask for some display text. At the moment this text is
just written somewhere with the little green line. (I think there may be
a problem with the display of a newly-created insert? There is
definitely a problem when you cut and paste them, they lose their
display string then). I have these working for inserting repeat
barlines. This is quite active.
Eventually this can become some graphical sign, so that it looks like it
should in real music.

> so that repeat bars, for example, are shown correctly? And how about scripts 
> that add things to the lilypond-output, 

> is there a way that the scripter can distribute a graphic
When we have the attaching of a graphic facility then, yes, we can let
the user specify a .png, .svg or other to be used from
d-InsertLilyDirective
The scheme script would then say something like
(d-InsertLilyDirective "lily=\\bar \":|\"\0graphic=
\"CloseRepeatBarline.xbm\"\0x-offset=20\0y-offset=0")

where the x-offset, y-offsets would be saying where a repeat barline
comes on the staff.
>  with his script which could be added to the staffs? 
> 
> And last to that: How are icons done?
It's all stock icons at the moment. It would require C-programming to
add custom ones.
>  Is there a way I can help with adding Icons for the menus? And can 
> menu-commands which are script have their own icon, too? 
Eventually... again it would require support in C.
Richard