RE: battle-plan for 2.5 development

[Juergen Reuter]

On Wed, 17 Nov 2004, Ralph Little wrote:

> ...
> However, I wholeheartedly agree with your assertion that the biggest
> bridge to cross is the non-mousey nature of the software, which is
> doubly large for non-techy musicians that have not encountered
> programming work. This could be tackled by some kind of online
> interactive tutorial that the user could launch into after installation.
> ...

The generic approach to solve this kind of problem is to build a GUI that 
uniquely maps to a command line interface for content manipulation.  This 
approach has been followed by *LOTS* of GUIs (just yesterday I looked into 
a rule-based reasoning software called "xclips", which does this kind of 
approach).

For lily, the approach could look like the following:

* The application displays a gnome canvas, that shows the music 
  that is currently being edited.

* In the GUI, there is also a "guile>" command line window.  On 
  application startup, either parse a .ly file and create a scheme 
  expression, or, if no .ly is to be loaded, start with a minimal, but 
  syntactically correct scheme expression that represents an empty score.
  (In this context, a scheme expression is called "syntactically correct" 
  if and only if there is an .ly file such that lily's parser would create 
  exactly this scheme expresssion.)

* The "guile>" window may be hidden by default (in order not to confuse 
  unexperienced users).  In this case, the GUI should provide a menu item 
  that will show up the "guile>" window on request.

* Optionally, when parsing a file on startup, file position information 
  (line/column) may be attached to atoms, such that e.g. for each note, 
  there is a line/column pair that refers to the file position (or is 
  lily's "cause" method already bound to musical atoms in scheme?).

* Design and implement commands for editing music structures on scheme 
  level.  Commands maybe include "add/delete staff/voice starting at 
  [moment]", "insert note after [position]", "delete note at [position]", 
  "add/change [property] of note at [position]", or similar.  More 
  general editing commands like musical pattern matching/replacing may 
  also be very interesting. Of course, finding a good representation for 
  "[position]" may turn out to be tricky (Which voice/staff? Which 
  moment?).

  Designing a sane, complete, but not too complex command line interface 
  for content editing is crucial and probably the most difficult part.

* Map each GUI action to a corresponding command on the "guile>" command 
  line.  That is, whenever the user takes a GUI action that is intended to 
  change the content, an appropriate command is created, pasted into and 
  executed in the "guile>" window.  

  Analogously to the point-and-click interface, pointing to a note on a 
  gnome canvas should somehow give you a proper "[position]" value that 
  can be used on the command line.  Similar, selection of, say, a staff 
  should give one or more [position] values.  A mouse action then should 
  be reducable to an editing command on the command line, using selection 
  and/or mouse position(s) as parameter(s) to the scheme function.

* Whenever an editing command on the command line is executed, the 
  musical contents changes, i.e. the gnome canvas may need to be updated.  
  In the very first approach, you would completely execute everything 
  starting with lily's processing stage on the modified scheme content.  
  Howver, this approach will result in poor performance and flickering on 
  the screen.  In a more refined version, you may want to think about 
  incremental compiler techniques that take into account that only a small 
  part of the music has been modified (but this is another big project, I 
  guess...).

Yes, I know, this all sounds like work for a couple of years.  I do not 
really expect someone to actually implement such a beast (although it 
would be really cool).  ;-)

Greetings,
Jürgen