Re: [zzdev] Things I'd like to do

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

On Mon, 31 Jul 2000, Benjamin Fallenstein wrote:
> 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.

My overall impression is that you're pretty much on the same lines as we
are.

> 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. ;) )

And I'm waiting for that other term so that I can change all the instances
in the code. Vizn?

> 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).

Not necessarily the raster: possibly just as well could be the viewcell.

This functionality is something that I definitely need as well so we
*will* figure out some way.

> 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?)

Sounds like it could be the solution, or at least the beginning of it.
I'll have to think about this. Ted, any opinions?

> 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.

It's a feature. Try the flob email thing and you'll see several views.
These will have different bindings so the bindings do have to depend on
the window.

We could implement a way to circumvent this if desired by putting a
"tunnel" between the two views which would proxy al events to the ctrl
view to the data view.

> 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.)

Are you sure it's VStreamRaster and not the FlobFactory you want to
override?

Any modularization which does not degrade performance terribly is more
than welcome. If you can figure out a good way to make this abstraction,
feel free to send a patch.

The VStreamRaster is currently, like TextCloud, in a very experimental
state, more a proof of concept than a real thing.

	Tuomas