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

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

On Tue, 18 Jul 2000, Benjamin Fallenstein wrote:
> Tuomas Lukka wrote:
> > Well, first of all, notice how modular gZZ is: it's easy to use the part
> > you want and leave out the parts you don't. Especially the graphics part
> > is based on flobs which you can easily create using simple Java.
> 
> Yeah, but I don't actually *want* to leave something out -- I just
> wouldn't have implemented all because I wouldn't have had the time.

No, I meant that it's easy to use parts of the gZZ code: you can for
instance use the structure but write a completely different user interface
on top (of course this is discouraged in favor of applitudes eventually).

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

> > Once something is clear i.e. specced fully with the structure <->
> > appearance mapping well defined, it will take about a day to get started
> > and then some days to polish it up. The problem is not coding: it's
> > defining and speccing.
> 
> Oh, wonderful! Are suggestions of help? :) (I may not be perfect at it,
> but I do have *some* talent for clean, well-defined structures.)

Definitely of help.

> > The one effect to fear here is that because it looks like a system
> > speaking a natural language, people will attribute too much intelligence
> > to it and wonder why it didn't realize what it had to do in some special
> > contingency that "should have been obvious" ;)
> 
> Oh, right. I never paid that too much thought... But I will remember to
> think about this, and tell everyone that computers are absolutely
> stupid! :)

You do know the anecdotes of people telling Eliza their life's stories ;)

> > All right. I think that the formatted text I'm planning now is slanted a
> > bit differently, towards text as media. What you need is something
> > slightly different. However, don't worry: what you need is actually *far*
> > easier to do properly than the formatted text I'm thinking of.
> 
> I'm not sure if you got me right on this one. I've had only time for a
> short look on the files you mention -- will have a longer one tomorrow
> -- but it seems they're concerned with drawing individual cells on a
> raster (like vanishing view or the old I and H); except TextCloud, which
> seems to have to be an editable and moveable flob. Neither are very
> helpful.

You're probably looking from a different perspective right now. Did you
try the textcloud: it actually has word-wrapped paragraphs of text inside,
and those are defined by vstreams. To see the word-wrapping, just write a
long enough paragraph.

> The problem, you see, is that I have "text inside text:" Move (the
> selected card) to (the stack the user clicked on). The Move [] to [] is
> the outer text, and (the selected card) and (the stack the user clicked
> on) are the inner texts. I want them to be shown as a continuous text:
> not in different cells, and word-wrapped. On the other hand, they need
> to have different formats (background color, foreground color, fond
> weight). They also need independent event bindings (mouse in etc.). My
> current prototype implementation uses the Text widget of Tk, which
> displays text with annotated "tags" (which aren't hierarchical like in
> HTML). If I get you right, you want to do an advanced version of this --
> Ted calls it "parallel markup." So, I figured if you make something like
> I use now, I could use that. :)

Yes, but the above things *are* in fact useful: you say "not in different
cells", but note that the TextCloud continuous stream *is* in fact
different cells. It's just that borders and backgrounds are not drawn.

Also, the text-inside-text would fit cells just wonderfully, i.e. 
"Move " in first cell,
second cell is something the user connects to somewhere which is then
shown by interpretation by going through the structure,
" to " is third cell.

Then you just need word-wrapping which is actually among the very next
features, i.e. splitting a displayed cell.

> I *do* need parallel markup, incl. event binding markup -- but generated
> by the applitude.

Event bindings would be handled by your applitude - see how TextCloud does
it.

> The reason I don't want to be the parts drawn in different cells is that
> I want to create a continuous text on the screen. One should be able to
> read it like any other text. 

Again, take a look at what the textcloud renders: it does exactly this: it
takes a lot of cells and renders them next to each other without borders.
Result: continuous text.

> Also, it doesn't make sense to show
> different cells which reference to the same thing. If I would have a
> progression of cells: "Move" -- "the selected card" -- "to" -- "the
> stack the user clicked on" then the cells "Move" and "to" would belong
> to the same function call. I want them to be considered an integral
> *unit* which would require making them *one* cell. If the other two
> tokens are in different cells, now, how could I form the textual
> progression from "move" to "the selected cell" to "to" to "the stack the
> user clicked on" ?

Easy. Like I said, cells are a structural thing. The edges around cells
are just a presentation detail. Also, the unit-by-interpretation can also
work.

> In my current design, I use background highlighting for this. When the
> user moves the mouse over "move", then both "move" and "to" are shown
> with a dark grey background, and the other two elements (which are
> parameters to the move-to function call) are shown with a light grey
> background. If the user clicks to select the function call, the same is
> applied, but with dark and light blue. All text associated with one
> element in the program will always have the same background and
> foreground settings at the same time. I consider this an elegant
> solution to the problem.

Could be done here as well.

> Thing is, how to implement it? And simplest here is to use a formatted
> text widget. Just that gZZ (as I understand it) doesn't have one. Yet.

Using flobs. Rendering cells next to each other without edges.

> >         g.setFont(f)
> >         g.drawString(...)
> 
> That's exactly my problem. drawString doesn't support text formatting,
> or text area event binding...

No, that's the presentation. What I mean is that you control the
appearance. The user interaction is controlled through ZZPrimitiveActions
and see TextCloud for an example of how clicking something can be
interpreted easily by the applitude.

> > So I think you *can* use ZZ as it stands today and if we talk some more
> > about what you need, I can probably help you get started with the raster
> > and flob coding.
> 
> I think I can safely conclude: Either I got you wrong, or you got me
> wrong. If the first is the case, please tell me how to find out what you
> meant! :) (i.e. where to look for what I need)

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" ;)

	Tuomas