[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Things I'd like to do
- To: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Subject: Re: [zzdev] Things I'd like to do
- From: Tuomas Lukka <lukka@xxxxxxxxxxx>
- Date: Mon, 31 Jul 2000 22:04:32 +0300 (EETDST)
- Cc: zzdev@xxxxxxxxxx
- In-reply-to: <3985C281.225C3510@xxxxxx>
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
> 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
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
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
Are you sure it's VStreamRaster and not the FlobFactory you want to
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.