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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

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

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

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

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

Will try to. (This will have to wait, though, till I can make Perl run
on my notebook to do the zob conversion.)

- Benja