Re: [zzdev] Dirty hack

[Tuomas Lukka <lukka@xxxxxxxxxx>]

> > > 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.
> 
> It is nice, but there is a catch which I'm not sure about.

This is exactly why I wanted your view ;) ;)

> When we
> render the cells' contents as SplitCellFlobs, these are *children* of
> the cell background flobs (necessarily, as there may be multiple
> SplitCellFlobs -- for multiline -- but only one background flob). If we
> then interpolate between a cell view and a text view (e.g. vstream or
> prez), the empty bg flob is interpolated to the text -- like it's now.

Excellent case. So in that case, the background *AND* the splitcellflobs
should interpolate to the full flob.

But text splitting in the normal cell is not easy to handle.

Maybe we should do text and graphics separately: interpolate spans to
spans? But that would be slow.

So one problem is that interpolation needs to be possible both ways.

> That's not going to work. We *do* want to interpolate the text, and
> similarily we might want to have special-case interpolation behaviors
> elsewhere. Actually I think we should go for the FlobSet-is-a-Flob
> thing, but we shouldn't lock ourselves up to a hierarchy; there should
> be interfaces to use different structures when necessary. I just don't
> know yet which.

Hmm, the question is, I guess, what the general cellflob needs to know.

An interface which would allow one flob to say essentially
"Trust me, I know what I'm doing" ;)
could be a pretty good thing.

Basically, a single cell can be
	- all at one place
	- shown in several places, with continuous rasters
	- split into parts
	- shown in several places, some split into parts

What comes to mind is that if the cell is split, then all the pieces
of the *same* split individual should animate to the same place.

Here, the case would be the single cell split into parts, and all parts
should interpolate to the same destination. The problem there is that
if the destination is a single cell, then actually we should plot
the split flobs for the complete duration of the interpolation...

We need an API for coordinates of a particular piece of stuff...

Very hard to do well generally.

> Hm, generally what about an interface to iterate over all children flobs
> of a flob set, direct *and indirect*? And then in the FIRST round
> selecting flobs for interpolation hierarchically, and in a SECOND round,
> iterating only over flobs which don't have an interpolation associated
> yet, interpolating flobs which cannot be interpolated otherwise.
> Possible algorithm would be a callback structure (like DepthIter), and
> then doing a recursive call to the flob sets which is handed the
> callback object. (Am I making sense?)

This doesn't help when you want one to many and many to one splitting.

> The FlobSet idea *does* appeal to me: it solves the depth problem. The
> flobs within a flob set can have different depths inside the set, but
> together be at the same depth in the surrounding flob set. Then, our
> cell views (formerly: flob factories) can structure the flobs they put
> into the flobset depth-wise.

The only problem there is OpenGL: the Flobset-in-Flobset will have depth
when rendered (since we don't want to do depth-sorting there,
necessarily).

> Side note: If I get Ted right, it has been the plan all along that cells
> be able to "draw themselves" (I remember Ted refering to that at several
> points). If so, why don't we just have a (FlobFactory) zob at the head
> of d.cellview, and call that from our standard cell views (flob
> factories)? We should make the call so that any exception in the custom
> cell view is printed out, but also invokes the standard cell view, so
> that things go on. And we can make custom cell view calling optional,
> allowing for a debug cell view which draws all cells plain.

Yes. This is the idea. Actually, the cells will only draw themselves when
the user requests that view, so we actually have a FlobFactory which finds
the real flobfactory on that path.

	Tuomas