[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: [zzdev] Re: [zzdev] Things I'd like to do
- To: zzdev@xxxxxxxxxx
- Subject: Re: [zzdev] Re: [zzdev] Things I'd like to do
- From: Benjamin Fallenstein <b.fallenstein@xxxxxx>
- Date: Mon, 31 Jul 2000 22:34:29 +0200
- References: <Pine.HPP.3.96.1000731215409.25619B-100000@xxxxxxxxxxxxxxxx>
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
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.)