Re: [zzdev] Nile

[Tuomas Lukka <lukka@xxxxxxxxxx>]

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

Hmm, isn't that the whole point of transclusions?

If you want to know its origin, you need to look at what scroll it is in.

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

I will but the jumping to other instances part is trickier.

That's because I'd like to have that as a space-level mechanism and
figuring the right structure to represent span overlap is ... interesting.

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

That's certainly possible. Still have to think about it for a while.

The basic question is, I think, whether we really want to duplicate those
cells in the structure or have a real, simple, unmodifiable reference in the
place where the stuff was included in. Because that way the structure of
copies would be clearer to the user.

> > > > 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.

Probably should be locked. And for vanishing view, we can probably choose one
of the most deviant unicode letters...

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

Actually, dimension=cell is what we will eventually have.

> 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...

Well, for dimensions that are only useful for a given applitude, the name
would have a prefix (like d.nile-struct).

Orthogonality is great.

> > 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!

Yes, this is what everything is aiming towards, little by little.

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

What is d.n?

> > 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!

Right. The atoms and molecules and ice-cream layers that Ted likes to talk
about are beginning to show up.

> > 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."

"First"?

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

well, by having dimensions be cells and the dimensions used in a particular
applitude would then be in that applitude's definition.

ZigZag and structure means that we don't really need to use naming anywhere.
OTOH, having names is very convenient for humans...

> > 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.

A cell can be in several applitudes. 

If I have an anchor in the text that I've connected to one applitude and connect
it to another, that would have to be noted somewhere.

	Tuomas