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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Hi all!

Tuomas Lukka wrote:
> 
> Ok, I think the time is now ripe for an applitude that does formatted
> text, hierarchically or otherwise structured.

This is *GREAT*.

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

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

Well, if you'd implement the formatted text now, (and in a way that is
usable to me,) I would *much* rather do the whole project with ZZ from
the beginning on.

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?

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

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.

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


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

How the hell am I going to do this?

I have a design (called the zaubertrank, TSAU-ber-trunk, which means
magic potion in German) which I hope for to make programming *much*
easier. The zaubertrank uses natural language instead of a cryptic
symbol code. So, instead of "selcard.move(clickstack)," it says: "Move
the selected card to the stack the user clicked on." Of course, if users
could enter sentences of this kind arbitrarily, no parser could get the
meaning today. But we don't let them enter this. We let them assemble
their programs from given expressions (or let them make new statements).
For the above, the user would first select the following from some menu:
"Move [which card?] to [which stack?]." Then, they would click on the
first undefined part, and select "the selected card" from some other
menu; same for the second undefined part, and "the stack the user
clicked on." New tokens like these, which can reference variables or
functions, can be created by the user.

I don't want to claim that with the zaubertrank, there's nothing to
learn before one can program. I just claim that there's much less to
learn, and that programs written with the zaubertrank won't have as much
of the "I can never understand this" flavor as classic programs. Sure
it's not stylistically perfect language, and will have many, many
repetitions. But one who is literate in the natural language the texts
are written in can get an understanding of the program's workings by
reading it. Still, the terminology may pose a problem. But it can never
be as bad as a Java program (or a Perl program!).

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

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

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.

You would benefit from this in various ways. You'd get one more working
applitude, which can give people an idea of ZZ in use. You'd get more
gZZ testers. (I, for starters, will need to use gZZ on Windows, a Mac,
AND Linux -- we use the last at our college.) You'd probably get some
contributions to gZZ by me. I'm much more likely to improve an existing
formatted text view than implementing one from scratch. Maybe you'd get
some code you can re-use for CLANG. I can't promise that the zaubertrank
will use concepts similar enough to CLANG that it can be re-used, but it
isn't improbable.

If the zaubertrank gets popular, of course, ZZ would get popularity,
too. :) Okay, THAT's not a very probable scenario...

All the best, and I hope to hear from you.
- Benjamin Fallenstein

p.s. There's a one-page website with some ideas at
http://www.zaubertrank.org , which also links to the SourceForge project
page, from which a design study of the editor, written in Python, is
available. -b.