[gsharp-devel] The good, the bad, and the truly ugly

[Robert Strandh]

Hello, 

I figured I should write down my impression with regard to my latest
updates of Gsharp before I forget. 

My concept of what the score pane should do seems to become clearer.
The latest modifications seem to confirm this.  The score pane should
define drawing functions and presentation types for visual music
material.  It should also define presentation methods for `present' on
those types, but only for the `score-view'.  The textual view should
be done by the application.  Ultimately, it should organize output
records so that they can be redisplayed in the right order, substitute
glyphs in stacks of notes, etc.  I tried making note heads into
presentations, but that slowed it down by a factor 2-3, which quickly
became intolerable for an entire page of music such as
rapsoden-sjunger.gsh.  When and if this gets faster, I will attempt it
again.  Highlighting staves does not change its appearance, because
the bounding box is already black on display.  It would be nice to be
able to alter the highlighting.  It would also be nice to have pointer
documentation (perhaps this already works) in the form of pop-up
windows that appear when the pointer is over a presentation (name of
the staff).  

The new keyboard command structure seems to work pretty well.  Now, we
can use a list of sequence dictionaries in which to search for
associated commands of a sequence of keys or to determine whether the
sequence of keys is a prefix of an existing command.  This will allow
us to have lists of `modes', each reflected by a sequence dictionary.
The order of the dictionaries reflect a priority, so that dictionaries
early in the list override the following ones.  I am planning to use
this to factor out key sequences such as #\a, #\b, etc to insert
characters in lyrics mode and clusters in melody mode.  Ultimately,
it seems like this stuff should be part of McCLIM, since many
applications will need it (Goatee, Phemlock, Gsharp, etc.).  That
would require some additional thinking about appropriate protocols. 

The drawing part (drawing.lisp) held up pretty well, even though there
is some ugliness in the dynamic mixin classes to get the x coordinates
right.  Some refactoring would be good. 

The abstract data type (buffer.lisp) is a mess.  I am sure there is
some design pattern in there that I did not respect, because there is
now tons of code duplication.  There are now two different kinds of
layers, of slices, of bars, and of elements (lyrics and melody).
Many, but not all of the operations are common, so should be
factored.  Creation is a mess though (use a factory?).  There is
duplication for each type.  Before adding percussion (another layer
type), the current code must be improved. 

I figured lyrics should be Unicode (I am reading up on this, but I am
still a novice) strings (which I now represent as arrays of fixnums).
Of course, that is a huge topic in itself.  I just put in whatever was
needed as proof of concepts.  The entire thing should probably be
factored out anyway (and again be part of McCLIM, I guess) since many
applications will need it.  In the immediate future, there would be
some joint work with Phemlock, since I imaging its buffers containing
Unicode (as some of us discussed at the LSM/RMLL).  Unicode support
also raises the question of input methods, i.e., what does one type on
the keyboard in order to produce a certain Unicode character.  This is
another issue not directly related to Gsharp.  For the rendering part,
there must be some existing stuff out there, though perhaps not in
Common Lisp.  GNU Emacs regularly shows me email with oriental
characters in it.  As I wrote, currently, I represent Unicode strings
as arrays of fixnums.  These arrays should be encapsulated in CLOS
classes with their own protocols so that the representation can change
in the future. 

There is some code duplication in the `accept' presentation methods
for the textual view, but I am not too worried about it, since I
suspect it is a simple matter of writing a few function and macros to
factor out the entire thing.  There are some patterns that are
repeated frequently: choose (and complete) from list, and it has to be
in the list (clef type, staff type); choose (and complete) from list,
but anything is acceptable (file names, create a new file if it is an
unknown file); choose a string that must not be a member of a given
set (creating unique layer names and buffer names).  Those patterns
could probably be captured in functions or macros. 

At some point, I need to read up some more on the `accept'
presentation method.  I would like to be able to type `return' at the
prompt asking for a layer, and automatically get the current one.
There are probably some similar situation to occur in the future. 

Slime failed on me several times.  In some cases, it (correctly)
reported errors that were very hard to get out of, and once I got out,
I got a different family of errors relating to X11, again hard to
get out of.  I found myself frequently having to quit Emacs, and
restart the entire process.  Perhaps it had to do with the particular
kind of problems that occurred, but at this point I am not sure I can
characterize them. 

Have a nice weekend, 
-- 
Robert Strandh

---------------------------------------------------------------------
Greenspun's Tenth Rule of Programming: any sufficiently complicated C
or Fortran program contains an ad hoc informally-specified bug-ridden
slow implementation of half of Common Lisp.
---------------------------------------------------------------------