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

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

On Mon, 31 Jul 2000, Benjamin Fallenstein wrote:

> Tuomas Lukka wrote:
> > > 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.
> 
> Huh? How can you hang the list specifying the bindings to apply to a
> raster from the viewcell?

I meant the states: if the bindings have (and they probably will) multiple
states then the states should probably be on the viewcell. 

The states are the biggest problem: right now we have the normal and the
insert mode. I may want to make F5 do something always in this raster and
"\" do something if not in insert mode and something else which only
touches insert mode. I could also want to make my own submodes, as in
Emacs' multi-key keybindings.

This gets pretty hairy.
 
> > This functionality is something that I definitely need as well so we
> > *will* figure out some way.
> 
> Maybe I'll do an example implementation which we can discuss then.

Sounds great!

> > > 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.
> 
> That's exactly what I meant. Suppose I'll do it...

The mechanism is in place, all it needs to have is an activation from
ZZWindows if two windows are on d.kbd-input-funnel or something from each
other. Mouse events cannot be funneled that easily.

> > > 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?
> 
> That could be a solution for the coloring; note, though, that the
> current VStreamRaster ignores the FlobFactory. :) Though this pbly could
> be fixed... But I also need a different structure than VStreamRaster,
> b/c my text isn't a list on d.2, but organized in a much more complex
> structure. I could, though, return a Java array of cells to be drawn
> successively. The function doing this needs to be put in a different
> class, connected through a new interface -- or in VStreamRaster itself, overridable.

So the abstraction that is needed is a convenience function that
creates flobs from a list of cells, strings and colors/styles?

What about bindings here? You want to be able to insert in someplaces but
not in others?

	Tuomas