Re: [zzdev] VStream, structured, formatted text applitude

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

On Tue, 18 Jul 2000, Benjamin Fallenstein wrote:
> Tuomas Lukka wrote:
> > > > What exactly do you mean by itemhandles?
> > >
> > > It's just another word for handles, which (as you mention d.handle) are
> > > probably familiar with. Ted uses the words synonymously in the Floating
> > > World design. I wasn't aware that gZZ has d.handle yet.
> > 
> > d.handle is just another dimension. You can create dimension d.fallenstein
> > just by adding it on the dimension list in gzigzag and rotating onto it
> > and making connections. Any string can be a dimension. Some, like d.clone,
> > have special magic attached to them.
> 
> d.handle hasn't? Shouldn't it reattatch the handle if another cell
> suddenly is the upper-left corner of a thing?
> 
> Here are Ted's words, which I understand that way:
> > Where to connect the handle to the item is fairly open. 
> > Efficiency question.  I suggest that the handle be
> > connected to a unit at the "upper left corner". 
> > (Negend in both d.1 and d.2).  If a thing happens to have
> > more than one upper left corner, connect it to all of
> > them, at the negend of all of the upper left hand
> > corner cells. 
> > 
> > Example.  A list of names and addresses with no title. 
> > It begins with the cells "Abraham | Arthur".  The
> > system detects that "Abraham" is the upper left corner
> > and attaches the handle there.  However, you later
> > decide you want first names first, so you make it Arthur
> > | Abraham.  The system reattaches it.  Then you
> > put in Aardvark | Exterminators and Aardvark becomes the
> > upper left corner, so the system reattaches the
> > handle to "Aardvark". 

This behaviour we don't have, since this is not at all well defined yet.
But this behaviour isn't really necessary for your applitude, or is it?
You can define the structure any way you want.

> > I think that I'm being unclear and also that there is not yet sufficient
> > documentation on how to do applitudes with gZZ. I think that we have 95%
> > or more of the code you need, you only need a little bit of glue code,
> > some new flob classes and that's it.
> > 
> > Please keep asking because then I know better how to explain this. I
> > should probably later format this conversation into a "applitude
> > developer's guide" ;)
> 
> Ok, got the message! I'll have a look at the code tomorrow, as I'll have
> to do several hours of traveling (in car, but not driving). I'll fire my
> questions back after that -- along with suggestions for the docs.

Great, thanks!

> Just one question before. You mentioned that I should use TextClouds to
> have word wrap and that I should render my text as flobs. Does that mean
> that TextClouds can word-wrap text made out of flobs? 

TextCloud is just a simple applitude to demonstrate word-wrapping and
beams (visualizing connections between shared content), and the "real
cut&paste" - the Cloud term is just the term the fact that you can have
fragments floating around.

It renders the vstream by placing flobs (one or more if word-wrap occurs
in mid-cell) on the canvas.

> How does that
> work? I.e. can I have flobs "Move ", "[which card?]", " to ", "[which
> stack?]", "." and together they form a word-wrapped TextCloud? And which
> classes do I need to use for that?

Ok, maybe I'm using the word "flob" a bit too freely and should move to
"blob". The flob I was talking about is simply a displayed thing on the
screen, which is associated with a particular cell.

Ted's real, structural flob is a special case of this. Maybe I should go
back to calling these "Thing"s again.

What you say is quite possible, and some of the code for the newer system
I'm writing just now.

	Tuomas