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

[Benjamin Fallenstein <b.fallenstein@xxxxxx>]

Fist, thanks for your quick response!

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.

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

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

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

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

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

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

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

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

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.

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.

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

That's exactly my problem. drawString doesn't support text formatting,
or text area event binding...

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

Thanks again,
- Benjamin Fallenstein