Re: [zzdev] Re: [zzdev] Dirty hack

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

> Tuomas & I said:
> > > Anyway, as I said, the parent flob stuff we don't need now. We can use
> > > it in the next release. We just should generally discourage the use of
> > > flobPaths in extensions (which we could if we'd interpolate to the
> > > nearest flob).
> >
> > Or we can simply make a FlobSet be a Flob itself.

Oh, and: it's not an "or:" we'll need nearest-flob interpolation for the
Matrix raster, and for others which show the same cell in multiple
positions (e.g. a vanishing view which places a cell again if it's
already there).

From a different eMail:
> One more thing about the interpolation stuff: one thing we want eventually
> is to be able to interpolate between permascroll spans that are referenced
> through different cells. 
> 
> So that we can first see one text stream on display and then switch to
> another one and see the cut&pasted pieces of text morph. This would be a
> great demonstration of something you can't do without permascrolls.
> 
> This doesn't fit the current nor the proposed framework well because both
> are based on cells. But this may be common: we may want to identify bits
> and pieces on the screen by other things than their cells. 
> 
> The big question is designing a fast enough system that still allows that.

Hm... couldn't we for the moment stick to spans and cells? We could also
add a flob type, so that only flobs of the same type would be
interpolated to each other. If we *do* want to interpolate between two
different flob types, we can have special-case interpolation methods;
so, a flob would have:
- a flob type, as a pointer (probably to a class?), not a string, so
that comparison is fast, and
- two arrays of flob types it can interpolate from and to (excluding its
own flob type, which it *must* be able to interpolate to).

That seems to make sense because an interpolation between two totally
different flobs ususally won't look very good if the flobs assume
they're interpolating to a flob of the same kind. A usage which comes to
mind is morphing a rectangle meeting type flob from the daytime demo to
the colored background area denoting the meeting in the daytime raster.
Standard interpolation wouldn't look very good, but we *could* change
the shape and color gradually.

Do you think that would work? Or would it cost too much time? Maybe we
have to try?

The flob types, together with the two-step interpolation (first inside
flob sets, then ignoring them), would allow the SplitCellFlobs as cell
contents to work right.

- Benja