[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: battle-plan for 2.5 development
From: |
Juergen Reuter |
Subject: |
RE: battle-plan for 2.5 development |
Date: |
Wed, 17 Nov 2004 18:02:37 +0100 (CET) |
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
- Re: battle-plan for 2.5 development, (continued)
Re: battle-plan for 2.5 development, Mats Bengtsson, 2004/11/17
- Re: battle-plan for 2.5 development, Johannes Schindelin, 2004/11/17
- Re: battle-plan for 2.5 development, Bertalan Fodor, 2004/11/17
- Windows text editors, Graham Percival, 2004/11/20
- Re: battle-plan for 2.5 development, Anthony W. Youngman, 2004/11/21
- jEdit, was Re: battle-plan for 2.5 development, Johannes Schindelin, 2004/11/22
RE: battle-plan for 2.5 development, Ralph Little, 2004/11/17
- RE: battle-plan for 2.5 development,
Juergen Reuter <=