Re: [zzdev] Re: [zzdev] Raster-specific keybindings

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> 
> On Thu, 10 Aug 2000, Benjamin Fallenstein wrote:
> > WOW. This was easy.
> >
> > I've just put raster-specific keybindings in. They work in the following
> > (I think quite elegant) way:
> 
> Would you care to explain it (preferably with diagrams) in Spec/ as well?

Will do, but without diagrams for now; I'm somewhat under pressure at
the moment and learning how to use the figure editors you use would
definitely make my deadlines impossible to meet. But you'll get the
specs (curseling, too) until... well, Sunday latest.

> > In the structparams for a raster, create a new param "databindings" or
> > "ctrlbindings." (That way, you can have different bindings when the
> > raster is selected in the left or in the right view.)
> 
> That's clever move #1
> 
> > Clone a bindings mode you want to modify for this raster.
> >
> > Connect the clone to the bindings structparam on d.1, and hang a
> > bindings list from it.
> 
> Excellent. But using the same bindings for two modes -- no, wait -
> I've got it: connect the two clones both on d.1 *and* d.2. Brilliant.

You can also use standard zz inheritance (which MIGHT be better in some
cases).

> > ZZKeyBindings1 will search for an intersection between structparam and
> > bindings mode cell on d.1 / d.clone. Thus, there's no string-based
> > matching or anything; you can change the name of the mode and the link
> > will still work.
> 
> Hmm, how efficient is that? How does it scale with growing number of
> rasters? It need not be the *Most* efficient part since it's only done
> once per keystroke.

I think of it as an experimental implementation, due to that it's a
feature which is quite useful for many things now. On the other hand,
when zz structure grows bigger and uses more serious, we'll definitely
have to make intersections fast on a general level (with hashtables or
whatever). Then, I think, this won't be much of an issue.

I'd say let's talk this through again when we actually have a
performance problem: it might well be we need to change the current
system out of design considerations before.

> > And I designed & hacked this in only one hour. I cannot help wondering
> > if there couldn't be a better interface for rastering that would make
> > something similar possible instead of the hours and hours of hacking
> > that went in my (still buggy & somewhat unfinished) level raster.
> 
> The problem is that rasters are an order of magnitude mo complicated. But
> no doubt they could be done better; we'll probably learn by doing. We just
> need to try to think of what abstactions would work when writing these.

*nod*. Well, I think one thing we should keep in mind to try out at some
point is shifting the responsibilty for the recursion needed in many
rasters to a higher-level instance, so that a minimal raster only
specifies a method that returns all connections of a cell in this
raster.

- Benja