Re: [zzdev] Nile

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Tuomas Lukka wrote:
> Umm, transclusions already work, at least on the fluid media level, in
> the TextCloud demo. To make them work in Nile on that level is a 15-minute
> job, approximately.

Oops, of course. I completely forgot about that. (They're not more than
an intermediate, though: you can't see where something came from, just
all other places where it is. But that might suffice for the moment.)

Could you do that job sometime? Because I'm not familiar enough with GZZ
spans, so it would take me much longer to do that. (I'd think a two
window structure would be best, where you transclude the selection in
one window to the other win, plus an action that is able to jump to
other instances of the same span?) 

> > Or we could make a spacepart that actually mirrors the substream in the
> > superstream (then we'd need to use a dimension from that subpart for the nile2iters).
> 
> Yes, a multi-clone of the cells could well be the right way.
> 
> The problem is implementing those in a reasonable way, and that's not going to
> be easy. For example, extending the bounds of the included text...
> 
> Hmm, actually I start feeling that maybe a nile-specific mechanism *would* be
> more appropriate as then you'd just move the marker cells to the right place
> in the stream.

So, a spacepart which deducts the substream from the two markers?

> > > Probably putting a single alphanumeric character in the special cell
> > > would make things easiest for the Nile2Iter&co...
> >
> > That doesn't make a lot of sense to me. I think you should really use a
> > model that looks along a special dimension if something's there, and if
> > yes, we have a special cell. How the meaning of that cell is determined
> > is another question -- that doesn't need to interest Nile2Iter (except
> > if it's a subpart, i.e. not "one character long").
> 
> It does belong to the units in Nile2Unit and forcing them to worry about
> it any more than they have to would create more complication all around the system.

Well, but putting a single character in the cell is kind of cheating:
the meaning is totally unclear if you look at the stream with e.g.
vanishing view. And if you edit the "strange" cell content, you will get
even stranger results.

> > It also doesn't seem to make sense to me: in that model, Nile would need
> > to know all other applitudes that work with it. That's NOT the way
> > applitudes are supposed to work, is it?
> 
> No, it wouldn't, actually. There'd be a global applitude table somewhere, or
> applitudes would be connected to the dimensions.

O.k., got ya. So dimensions would be associated to applitudes (based on
string-matching). I don't particularily like that, for applitudes won't
be able to use the common dimensions, and if two applitudes use the same
dimension, there'll be great trouble, but I do see it has it's pros...

> What we have is a bridge between two worlds, for instance a calendar and
> a text stream. The display code could be coming from either side -
> as a matter of fact, the idea would be for the applitude that reaches
> that cell to basically send out a call "who'd like to show this cell
> or connections to it" and the other applitudes jumping in and splatting
> their views about it on the screen, with priorities obtained through
> user preferences and other methods.

Oh! I hadn't quite got that before. Makes a lot of sense (in a world
beyond WYSIWYGOP). And if you want a special way of connecting two
applitudes (like for nile, stuff that can be integrated in the text),
which was the kind of problem I was mainly aiming at, you just program a bridge.

*That* is something I would really like to see soon. Wow!

Hmmm... does that mean the d.n dimensions would be shown with
vanishing-like views in this context? I.e., you could seamlessly
integrate d.n connections with Nile streams etc.?

> This way, moving from between the text stream and the calendar could
> be fluid.

And near the variable I include in a Nile stream, I could show the
program where that variable comes from, and vice versa... oh wow. ;o)
I've always seen gzz inclusion as a connection you can follow both ways,
but I never realized that it's not at all that hard to program a general
system that shows these connections!

> > Of course there can be different "views" on the same data structure
> > belonging to the "sub-applitude," meaning the data can be integrated in
> > different data structures of different "master applitudes" in different
> > ways at the same time.
> 
> Yes. It depends on where you come to it from. That's why I don't like "master".

I put it in quotation marks because I didn't like it either. I was
solely refering to the process of view building: the view that calls the
other view is the "master."

> Ok, except for terminology we are along the same lines here. Except
> that the applitudes will not use ZObs, but rather, simply have their
> own dimensions which are associated to that applitude somewhere else.

Again, I fear we're running into namespace problems here. Any plans on
how to prevent that?

> Now the question remains of whether it's possible to make it efficient.

Hm -- should be, because a cell could know the applitudes it belongs to,
by checking its connections on the respective dimensions while being loaded.

- Benja