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

[Tuomas Lukka <lukka@xxxxxxxxxxx>]

On Tue, 18 Jul 2000, Benjamin Fallenstein wrote:
> The thing is, I've been planning a project (description below) & have
> started to work on it which would be *much* easier to realize as a
> ZigZag applitude; plus, I would love it if it was compatible with the
> future ZZ world. ZZ would be so much help that I've even thought about
> implementing an own small ZZ-like thing, to have the structure. So, if I
> could do it in gZZ, it would be *so* much less work! (And I would like
> to support ZZ. One year or so ago, I wrote a posting to this list
> stating that I "could easily imagine the paradigm to be the future of
> computing." So...)

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.

> But it needs two features currently not implemented in ZZ: itemhandles,
> and formatted text. And if I would have to work on a gZZ version with
> the second now, it would actually make everything harder than just
> implementing a tiny subset of the desired functionality, just enough to
> make my project work. I intended to switch to ZZ later, when it becomes
> fully available...

What exactly do you mean by itemhandles?

> Do you have any idea how long this will take to implement? It would be
> good if I could have a running (if buggy) version by mid of August, so
> that the design can be tested out and made final for the first version.
> This one I need by mid of September. How do you see the chance that the
> formatted text stuff in gZZ will be implemented by then?

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.

> > The big questions are: how
> > to store the formatting information (paragraph, heading, etc.) connected
> > to the vstream? How to store the other structure and make sure that
> > operations like cut&paste on the vstreams produce the right results with
> > the other structure.
> 
> For my project, I need the following, but I would suppose your
> implementation will have that anyway...
> 
> AUTOMATIC GENERATION. Most text my applitude needs to show won't be
> editable by the user, but composed of non-formatted text the user enters
> elsewhere. My applitude will put these texts together and format them. A
> mixed mode would be preferable, in which some parts of the text can be
> edited and others not, but that isn't required. (Outside of editable
> areas, the text widget may *not* display an insertion cursor or a
> selection!)

Shouldn't be a problem, with a little trickery.

> CUSTOM INTERACTIVITY. Parts of the text should be able to react to
> (mouse and possibly keyboard) events in a custom way. I would need mouse
> in, mouse out, click (mouse down and mouse up), and drag&drop events. I
> know gZZ isn't strong on drag&drop, but it would be enough if there
> would be separate mouse in, mouse out and mouse up events to be used
> when the first mouse button is pressed, which get as parameters both the
> text area in which the mouse down was performed, and the text area the
> mouse cursor is currently in. -- Note that all this isn't specific to my
> applitude: it would be useful for other applitudes e.g. to implement
> hyperlinks.

Works already: the keybindings are defined in the structure and reacting
differently to mouse clicks on different flobs is allowed.

> By the way, the automatic generation requirement of course includes that
> the automatically generated text shouldn't be saved to a vstream. The
> process is more like a special form of cloning: the cell doesn't have
> contents by itself, really, but contents which are generated from (an)
> other cell(s).

Well, this can be done either by running a background process which
inserts the text or by interpretation, as you say.
 
> --- Okay, some words about the project in question. I'm going to teach a
> course at my college on something called "interactive storytelling" this
> fall (it's a bit like computer games). Part of this will be programming,
> and I need to work with people who are completely uninterested in
> computer science and know virtually nothing about it. I made the
> technical requirement that one should "know how to read eMail" (so that
> one can switch the computer on and know how to work with a PUI -- I can
> hardly require them to know ZigZag, can I? :) ) So, I need a programming
> system which those people can learn fastly, as programming won't be the
> topic of the course but only one skill taught.

Sounds like fun.

> reading it. Still, the terminology may pose a problem. But it can never
> be as bad as a Java program (or a Perl program!).

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" ;)
 
> I think it's clear now what I need the "formatted text" view for. (It
> will need to support highlighting of the scope associated with some
> token by changing its background, for example.) 

Ok, this is probably slightly different but see below.

> The itemhandles I need
> because programs written with the zaubertrank will usually be concerned
> with things, not individual cells. The example above shows this: there
> is no thought to be paid about how a card is represented, or how it is
> connected with its stack. So, we need a way to talk about the thing as a
> whole, not its internal structure. (The function called, move [which
> card?] to [which stack?], needs to know about this, of course. But the
> novice zaubertrank programmer doesn't.)

Well, these kinds of item handles are actually already working: just
define the structure so that d.handle goes from the handle cell through
the item and then refer to the handle cell along d.ref.

> The zaubertrank will be free software under the GNU GPL and/or LGPL.

Excellent; this gives me much more motivation to help you ;)

> It would be nice if you could tell me if your ideas of the formatted
> text view/applitude support my needs, and if it will be there in time
> for my deadlines (esp. the second one, mid-September for a version
> without big bugs, is *important*). If I can be of any help, let me know
> (I'm familiar with Java in general, but not formatted text stuff, and
> not gZZ code -- although I'll definitely have a deep look at the latter,
> esp. as I'll have to implement my applitude). B/c if gZZ can help me, I
> can stop my work on the current design study implementation of the
> zaubertrank, and devode my time to the gZZ version.

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.

What you need is simply your own raster, some of your own flobs and there
you go. Because basically, what rasters do is they start at a view cell
and move through the structure and take information from there and put it
on display through the flobs. The flobs may paint *WHATEVER* graphics they
want, including text.

In addition to this, you need to write your own operations, but those are
simple once your structure is clear.

Take a look at flob/VanishingRaster for an example of a raster; it's a bit
complicated because it does many things but that's the general idea. Then
look at flob/CellFlob1 which is the simple cell flob which you see by
default when looking at ZZ. It simply does

	g.setFont(f)
	g.drawString(...)

which is not that difficult to duplicate.

Then, take a look at TextCloud (it, at the moment, still uses the ZZCanvas
stuff which is now deprecated but I'm going to convert it soon): that's an
example of how you can include a really modular applitude. You start it by
moving the left view's cell down-right-down to TextCloud.TESTWIN and
pressing enter (see the other docs for more).

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.

	Tuomas