[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Applets
- To: zzdev@xxxxxxxxxx
- Subject: Applets
- From: Brent Turcotte <brentt@xxxxxxxx>
- Date: Wed, 20 Oct 1999 15:17:01
- In-reply-to: <19991019235645.C4736@xxxxxxxxxxxxxxxxxxxxxx>
- References: <380BC7DA.E0D0DB21@xxxxxxxxx> <380BC7DA.E0D0DB21@xxxxxxxxx>
I have mentioned something I called a 'possibility generator'
on zigzag@xxxxxxxxxxx When zigzag is mature I want to program
the possibility generator. For now, I will design it, and
probably pseduo code it.
I hear that zigzag will be ported to other programming languages.
Will that mean that applets will have to be reprogrammed
for each language? Will there be an API?
It is early, documentation will be coming describing how applets
will interact with zigzag. But I can't help it, I want to
speculate. I not sure if I am correct or if there are better
ways of doing it than what I describe here.
Types of applets:
- Applets which add commands to zigzag.
- Global options for zigzag. Since there are only so many keys
on the keyboard, there needs to be an applets which will allow
to configure key assignments. Also to prevent key assignment
conflicts.
- Applets which generate cells and links. Examples: possibility
generator and tables. If you have a rank of floating headcells,
then the command 'create new cell' will create a parallel rank of
cells, instead of a single cell.
- Applets which are views. The views be based on the whole of
zigzag dataspace, a dimensionally limited view, or a selection
of cells.
- Applets which link views. For example, the floating headcell
view need to be connected to the I and/or H view to be useful.
Also, it might be desirable to link cursors -- so if you move
one cursor others move simulataneously.
- Applets which execute commands in cells. Cells can contain
plain text, graphics, math, or macros or whatever you wish.
- Applets which restrict access or cells or links. These cells
and links can be password protected, or just plain hidden for
clarity. Or you could force a user to fill in cells before
continuing. Or alert the users of unfilled cells.
Undoubtably there are kinds of applets. I am not sure if it
is possible to prevent the formation of application prisons in
all cases, although they will be much less severe and much
rarer.