Re: [zzdev] Dirty hack

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas & I said:
> > sorry, hadn't time to fetch eMail before. I'm very busy this week &
> > don't have time to code, really. Maybe we should just use the old flob
> > API for the moment? It would be great if we could have a multiline quad
> > view in the first stable release, but I'm pretty sure we won't. On the
> > other hand, if you can think of an easy and efficient algorithm for
> > interpolating to the nearest flob always, that would make the Matrix
> > view usable (for non-trivial structures) -- which probably would be a
> > good thing. If it's just the hacking, I can do it on the weekend, but I
> > don't have time to figure out how it should work.
> 
> I can do the hacking but I want to have your view of what is needed.
> 
> > 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. 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.

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.

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

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.

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.

> That could be the single most elegant thing to do here. It also has the
> benefit that if we manage windows ourselves at some point, then the
> flobset can simply define itself to paint over its background and ta-dah:
> same code works there.

We'll even have the code for that, because we paint cell backgrounds
already. :) Like the idea a lot!

> I think this is probably the way to go. I do like the multiline quad view
> and will try to hack it to work before stable (it'll still take a while).

Cool!

- Benja