Things I'd like to do

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Here are some changes I need in gZZ for my applitude, if I want to keep
my current design, and which I would like to make. Please tell me if
they're consistent with the current design decisions, i.e. if they're
o.k. with you.

RASTER-SPECIFIC BINDINGS

(I'm using the terms raster and toplevel not because I wouldn't agree
with you, Ted, that most current "rasters" aren't rasters really, but
because the term is clearly defined at the moment. When we have another
term, I'll switch. ;) )

I'd like to add the possibility to have special key bindings for
FlobRasters. I need this for my applitude, but it is also useful for the
vstream and tree rasters; for example, to bind the Left key to "go left
if there's a leftward connection, and if not, go one level up in the
tree." That would require a connection from the cell specifying the
raster to a bindings list, which could inherit the standard bindings
list (which would also be used when no raster-specific bindings list is
defined).

Yes, I'm aware that this interferes with the current system of changing
modes by accursing different key binding lists; maybe one some two
dimensions the intersection of the raster cell and the accursed key
bindings cell should be searched, and from the intersection list hangs
the bindings list?)

THE CONTROL VIEW FOCUS BUG (or is it a feature?)

When the Control view has the focus, the key bindings work on it as if
it were the Data view, i.e. jil, moves the Control view and sefc moves
nothing. (This has come with the change to two separate toplevels.) Is
this intended or a bug? It bugs *me* (and also makes use of my applitude
harder). If it's not intended, I'd like to change it.

VSTREAMRASTER MODULARITY

I would like to base my applitudes special raster on VStreamRaster, so
that future improvements in VStreamRaster (there are several to come, if
I'm not mistaken) will be reflected in my view. Thus what about making
VStreamRaster a bit more modular inside, so that forming the list of
cells to be displayed in a separate method, as well as the generation of
the SplitCellFlobs? That way, I could just subclass VStreamRaster (and
probably SplitCellFlob) for my own raster.

Or would you recommend making a new class based on VStreamRaster's code
and updating it when VStreamRaster is updated? Or calling VStreamRaster
from my raster? Or something else? (You know, I'm talking about the
text-inside-text-and-cells-with-different-colors-and-shadows-when-mouseovering
stuff.)

- Benja