fwSpecAdds3-D5
===06.07.31
fwSpecAdds3:
FLOATINGWORLD SPEC FURTHER TWEAKED,
from meetings of 26-7 July.
Note: "FloatingWorld", "Xanadu", "ZigZag" and other names have
various trademark status, registered and unregistered.
Here are results of discussions amongst Ted, Rob and Marlene.
I regret that this may not be at our usual level of clarity, but time
is very short.
===CONTENTS: headings from below
===EXPLAINING THE PRODUCT
===WHAT THE PRODUCT IS TO BE
===THE HOLY GRAILS OF THE PRODUCT
===DEVELOPMENT SCRIPTS; CLOSING THE SCRIPTS
=HOWEVER, WE'LL KEEP SCRIPTING
=AND HOWEVER, PAYING USERS MAY SCRIPT
=THE DANGERS OF SCRIPTS
===HYPERCAPS-- NEW CONTROL ALPHABETS
=OUR NEW CONTROL ALPHABET, "Spatial Characters"
===ZIGZAG AT LAST: FZZ IS HERE
=THE FIRST VIEW
=NO COMMANDS YET
===CELLVIEW IDIO SPECS
===SPECIAL FUNCTIONS TO BE DONE
=KEYBOARD FILTER ROUTINE
=HOPSWITCH ROUTINE
=TIMERS
=EXECUTION DIMENSION
===THE KEYBOARD FILTER (KBF)
===SELECTIONS IN FLOATINGWORLD
=SELECTIONS FROM OUTSIDE FLOATINGWORLD: DRAG AND DROP
=SELECTIONS FROM INSIDE: SLICES, ETC.
=SELECTIONS FROM INSIDE: DOCUMENTS AND TEXT BY MOUSE
===CELLTYPES
===CELL MODES
===CELLIDs AND CELL MOVEMENT
=MOVING CELLS BETWEEN A USER'S SLICES
=CLONING CELLS WITHIN A USER'S SLICES
=CLONING CELLS TO ANOTHER SLICE
=MOVING TO ANOTHER SLICE AFTER CLONING
===SLICE FUSIONS AND SPLITTINGS
===SLICES AND PACKAGES
===SLICE TYPES: DIFFERENT SLICETYPES AND VARIANTS
=SLICE NAMING AS A CROSS-PLATFORM ISSUE
=MULTIDOT SUFFIXES
=SLICENAME VERSIONING
===SLICE TUPLES EXACTITUDE
===BUFFERNAME VERSIONING
===SLICE BACKUP ISSUES
=OTHER DIRECTORIES
===THE SCENELIST: misc. points
=LOTS OF CHANGES NEEDED
=THE d.1 PROBLEM
===SWORFING: THE PROBLEM OF SWORFING CONNECTION-LINES CORRECTLY
===MULTIPART CELL ADDRESSING ISSUE
=TRANSMISSION OF CELLS, POSSIBLY CONTENT
=ORIGINS OF "SERVER/SLICE/cellID"
="SLICE OF ORIGIN" IS NOT USUALLY A CONCEPT.
=SENDING NAMED SLICES BETWEEN USERS
=CONNECTION OF SAME CELLS
===SCRIPTING
=WHEN CAN WE EDIT SCRIPTS AND SEE ZIGZAG RESULTS?
=SCRIPTING ENHANCEMENT NOW IN PLACE
=SCRIPTS IN CELLS
===ZIGZAG VIEWS
=ZIGZAG VIEWS: TO SELECT A CELL AS REFRESH CENTER
=ZIGZAG VIEWS: WHATCHAMACALLIT
===OUR LANGUAGE, recently called "Gartersnake"
=MOST FUNCTIONS RETURN LISTS EXCEPT--
=THE MYSTERY OF PYTHON TUPLES, NOW SIMPLIFIED
=DIMDESIGNATORS
=NONEXISTENT DIMENSIONS
=DIMENSION SYNONYMS
=PYTHON TRUTH-VALUES
=CHANGES FROM ROB'S GARTERSNAKE WRITEUP (of 06.07.15)
=LOOP DETECTION
===NAMING AND RENAMING ISSUES
=TERMS NEEDED
=BEST NAME FOR OUR SCRIPTING LANGUAGE?
=NEW TERM
=MAJOR NAMING OF PARTS
=SCENELIST DIMENSIONS-- RENAMING THEM, REALLOCATING THEM
=THE STRANDCHUNK ISSUE
===ISSUES UNRESOLVED
=(HYPERTIME FOR ZIGZAG UNDO etc)
=AUDIO
=LINK-LOCKS
=VINKS
=CAPS-LOCK TIMEOUT
===GLOSSARY FOR THIS DOCUMENT
===EXPLAINING THE PRODUCT
Aside from the technical problems, we have a tremendous issue: how to
explain this system to people, and its parts. FloatingWorld has many
levels and isn't like anything else. The next few paragraphs are my
latest attempt.
FloatingWorld is a Quasi-Operating System (QOS). While it is not
an actual operating system (with low-level drivers), its levels
correspond roughly to what users see in an operating system of today.
The internal mechanism is ZigZag(R), a data and computing engine.
This corresponds roughly to the guts of the conventional operating
system. Most users will not go into the ZigZag level, just as most
users do not go into the operating-system level of Windows or the Mac.
Corresponding to conventional windows, we have three-dimensional
Scenes and Shows.
Corresponding to conventional applications which do not connect to
each other, we have Applitudes (which do connect to each other).
These include LifeDimensions (which you may use to keep track of much
of what you do.) Users may create views, or "skins," which change the
ways these are seen.
Corresponding to conventional database and spreadsheet, we have
data arrangements in ZigZag (zzstructures). Like spreadsheet, this
offers light numerical programming.
Corresponding to conventional files, we have "slices"
--interpenetrating packages of zzstructure.
Corresponding to conventional document viewers-- notably, Adobe
Acrobat-- we offer CosmicBook, which stores documents in Outspread
format, with as many links showing as you want.
(Buffering the scenes, we also have zzstructure packages.)
For those who reach the ZigZag layer, there is Geography (layout),
Clockwork (mechanics), Plumbing (flow-- programs and flowing data).
===WHAT THE PRODUCT IS TO BE
The product, as presently defined, will have two versions--
- the Free Reader, with editing and scripting not available to
the user. This will open documents and graphics, with links, and
allow you to read and explore them. If you pay to unlock it, you get
the second--
- the Editor, the paid product-- a full multidocument hypertext
editor, with scripting available and full ZigZag available.
I think it best not to give direct ZigZag access in the free reader,
especially by disabling ZigZag views and Kblang operations; perhaps
not even in the early paid reader. This gives us less to maintain at
the beginning, and makes it easier to explain the system
incrementally.
===THE HOLY GRAILS OF THE PRODUCT
I believe Rob has committed to the first three of these--
Holy Grail 1
Outspread documents with profuse transclusions and links, turnable
on and off
Holy Grail 2
Distributable Outspread Document Package
Holy Grail 3
Pullacross Editing
Holy Grail 4
Network Editing, especially with audio
===DEVELOPMENT SCRIPTS; CLOSING THE SCRIPTS
In the development phase, we will be writing scripts for various
important functions.
When we build the distributable, these scripts will be transmuted--
closed up so they can't be changed, and compiled into the one unified,
monolithic program package.
Rob is checking into methods for this Rollup operation, which will
have to be done repeatedly, possibly without his help.
=HOWEVER, WE'LL KEEP SCRIPTING
Meanwhile, we will be scripting for the first package.
=AND HOWEVER, PAYING USERS MAY SCRIPT
Those who pay for the editor will get the privilege of writing their
own scripts, exchanging scripts with others, and hiring our Certified
Customizers to add scripts to their setups.
=THE DANGERS OF SCRIPTS
I want users to be informed that running a script can be every bit as
dangerous as running arbitrary programs in Windows.
===HYPERCAPS-- NEW CONTROL ALPHABETS
Based on the Keyboard Filter (below), it will be possible to create
new control alphabets comparable to shift, ctrl- and ALT-.
- "Shift", or capitalization has been around since Charlemagne.
- "Control characters" were put into ASCII ca. 1960, but came from
telegraphic control codes. Don't know when it was made an alternative
alphabet rather than random codes.
- ALT was added by Microsoft to correspond to Unix (or is it just
Emacs) META.
With our Keyboard Filter, anyone can create their private control
alphabet. We will be delivering the system with one of our own--
=OUR NEW CONTROL ALPHABET, "Spatial Characters"
Based on the keyboard filter (see below), we will add our own new
distictive control alphabet to the system.
We now add: "Spatial", as in spatial-A, spatial-#.
We will use spatial characters especially to control our spatial
functions (flying around and editing in space), but they may be
assigned to any operations through the keyboard filter.
We say "spatial a" to distinguish it from "space a," a full spacebar
up and down followed by a. In the spatial alphabet, you hold down the
spacebar and type a key. Alas, you will probably have to let it up
again and press the spacebar again for successive spatial characters.
Note that spatial characters must usually be caseless, since shift-up
and shift-down may not fit the sequences we want, and Caps Lock has
its own problems. (If we want uppercase and lowercase spatial
characters, however, we can specify Spatial-Capital-A, meaning
spacebar-down shift-down A, or Capital-Spatial-A, meaning shift-down
spacebar-down A.)
===ZIGZAG AT LAST: FZZ IS HERE
While earlier builds of FloatingWorld have had robust zzstructures,
nobody could see them. Finally we have a view. Rejoicing! Finally
we can call it Fzz (FloatingWorld ZigZag).
=THE FIRST VIEW
Rob has done a first ZigZag view. It is rather like the Zzz view in 3d
- no unifreshment, ranks go on and on repeating.
BUT
- cells are visible cubes
- it has transparency, as cells get further away you can see
through them (looks nice!)
- it seems to have haze [must check]
Rob will soon improve the View.
=NO COMMANDS YET
Still no zigZag commands as yet. These are not Rob's job any more.
They must for the most part be left to the Scripting levels.
EXCEPT Rob will do-- (detailed below)
-- Keyboard Filter routine
-- hopswitch
-- timers
-- jump to d.xeq routine on cellclosure
===CELLVIEW IDIO SPECS
Part of the ZigZag specification has long been Idiosyncratic Cellviews--
- cellviews where each cell may have its own view or picture (done
with cellcover celltype)
- cellviews that allow different cell types to have their own views
How do the latter? When we go to a zzview where celltypes are allowed
to have their own viewspecs, where are they kept?
Answer: on a dimension like "d.mastershape", so that we can specify
- size
- shape
- covercell
- color
etc.
Rob says these are at the script level and not his problem.
===SPECIAL FUNCTIONS TO BE DONE
Rob has kindly agreed to do four special functions--
=KEYBOARD FILTER ROUTINE (explained below).
=HOPSWITCH ROUTINE (described in separate fwSpec email)
=TIMERS
This came up when I proposed to have a routine that would turn off
Caps Lock after a second or two of disuse. Rob says he can do an
"execute on timer" instruction without too much dificulty, proposing
the form
zz.executeontimer
details to come.
=EXECUTION DIMENSION
The execution dimension, d.xeq, has long been in the ZigZag specs (and
even on the Gzz dimension list, though nonfunctional-- except that
Benja Fallenstein at one point implemented a different meaning of it
that worked quite nicely).
The execution dimension as I have designed it is a very simple way of
putting spreadsheet capability into ZigZag. It works like this:
- when a text cell is created, ZigZag looks to see if there is a
connection +d.xeq
- if so, jump to a routine [not now written, so a dummy
temporarily] that looks posward on d.xeq for a formula and performs
the calculation there, putting result into a cell
- when that cell is closed, do the same check again (allowing it to chain)
- these cells can be embedded anywhere, e.g. in spreadsheets or
printable documents, or just Around.
- (Later: if multiple cells close simultaneously, they'll have to
stack; but we'll worry about that later.)
Rob, somewhat amused: "There are worse ways of doing it."
The only implementation it presently needs is the on-closure check and
call for routines which enclose cell text content.
===THE KEYBOARD FILTER (KBF)
The keyboard filter gives the user complete control of key functions,
including the definition of new compound keystrokes and new control
alphabets. These may be user-configured at any time.
It just does this: When a match has been found to a keyboard sequence,
a progcell is executed.
The Keyboard Filter makes ZigZag into a Reconfigurable State Machine--
'depending on how you set up the wheels,' like the Enigma.
The Keyboard Filter cannot be disabled; if the user has access to the
ZigZag level at all, it's possible to reconfigure the Keyboard Filter.
Rob sez: We can be sure (under the Wintel BIOS) that any TWO
downstrokes will be recognized in order. MORE CONSECUTIVE DOWN
KEYSTROKES CAN'T BE GUARANTEED, may even vary between keyboards.
E.g., down or up--
- shift
- ALT
- spacebar
followed by Whatever.
[SEE ENCLOSED PIC]
HOW KBF WORKS: an incoming keystroke goes to the keyboard filter. If
the key matches a routine, that routine is executed. If it does not
match any routine, the string is sent back out for use as a typed
string. If there is a partway-match, the KBF routine hovers waiting
for the next keystroke.
The keyboard filter is a succession of wheels. The wheels are lists
on d.2, which are connected sideways on d.1 at specific cells. For
visualization we suggest making the wheels hierarchial, though for the
same functionality the upper wheels (higher posward on d.1) could be
broken up into separate wheels.
Each connection on d.1 is recognized as a wheelhandle, used to
distinguish the end of a comparison strip.
The operation is as follows.
Each character typed is presented to the wheel until a match is found.
- If an executable routine is next to it on the next wheel
+d.1, that routine is executed.
- Otherwise, the virtual pointer of the KBF then waits for the
next character.
Stated perhaps more exactly:
KBF: (Await keystroke)
KEYSTROKE ARRIVES.
TESTLOOP
test against current cell.
IF MATCH GO RIGHT +D.1
if that cell is executable, EXECUTE
else WAIT
IF NO MATCH
STEP +d.2
IF THERE IS HANDLE +d.1, EXIT WITH CURRENT STRING
IF NO HANDLE, REPEAT TESTLOOP
For now, this will be implemented with hovering mechanism rather than
contact mechanism, since it's easier.
=WE COULD DYNAMICALLY MODIFY OR REPLACE THE WHEELS! But that's kind
of like program modification. ("Deep water," says Rob.)
=TYPETWEAK ROUTINE
A second routine needed for this is a general typetweak routine which,
when a match is found, returns with some other string.
- if it is a preset string, it will be waiting +d.1 of the
typetweak routine.
- if it is a string dependent on the input routine, there'll need
to be a more specialized typetweak routine.
=JAPANESE AS SPECIAL CASE OF KBF OR TYPETWEAK
We have talked of doing Japanese. If we do, we'll let the user do
input the standard way-- type Romanji, then flip through plausible
alternatives. This could be done with the KBF.
===SELECTIONS IN FLOATINGWORLD
=SELECTIONS FROM OUTSIDE FLOATINGWORLD: DRAG AND DROP
"Drag and drop" is no problem cross-platform, says Rob.
=SELECTIONS FROM INSIDE: SLICES, ETC.
To select things from inside the program-- slices to bring in, etc.--
the best thing on the table is the Hopswitch.
=SELECTIONS FROM INSIDE: DOCUMENTS AND TEXT BY MOUSE
It is now possible to select individual strings within a flying
document by mouse.
This implicitly selects a document that is in view, and a tetroid within it.
(Note that "unproject" is the computer-graphics term for the function
that does this, returning 2D or 3D coordinates (x,y,z) of an object.
This can involve intricate sorting based on the shapes of overlapping
objects.) [I don't fully get this.]
===CELLTYPES (at last becoming needed, though only a few afre needed
immediately)
- text (default) -- CONTENT DOES NOT CHANGE WITHOUT RENAMING THE CELL
- unbrokenspan [formerly Rob's 'strandchunk']-- PRESUMABLY
CHANGEABLE CONTENTS
- cursor [unless hovering]
- dimdesignator or dimkey
- executable (Python script being first type)
- result cell, numerical
- hopswitch
- compound text? [nbk06.07.26p49]
- preflet
(Preflets have a far-off yearning for cells in other places.
"Like most of us.")
cover
===CELL MODES [need better term]
A cell's mode is independent of its type.
clone
remote clone
clonehead [prob.not a mode]
headcell [prob.not a mode]
===CELLIDs AND CELL MOVEMENT
[This is a resolution of our discussion which contains new material.]
A user's cellIDs are assigned in ascending order, no matter what slice
they appear in.
=MOVING CELLS BETWEEN A USER'S SLICES
A cell may be moved to a different slice with no change.
=CLONING CELLS WITHIN A USER'S SLICES
A clone in the same slice is a plain clone.
A clone made in another slice is a remote clone.
=MOVING A CELL TO ANOTHER SLICE AFTER CLONING
The local clones on this slice are made into remote clones, and the
remote clones in the destination slice become local clones.
===SLICE FUSIONS AND SPLITTINGS
This is principally a selection issue.
- two slices to be fused are selected by Hopswitch; some keyboard
command fuses them.
- in a slice to be split, the user marks the cells to go into a
different slice. Some keyboard command causes the slice to be split.
-- preflets replace the connections where required.
-- clones and remote clones are appropriately replaced.
===SLICES AND PACKAGES
A slice is a collection of cells and possibly content, either for
local use or transmission.
A package is a slice set up with specific pieces, portions or sections inside.
Strongly relevant: "Docupack" memo (fwSpecDocupack-D1w-- which
superseded previous version, D1x).
I'll be further revising that memo in a few weeks.
===SLICE TYPES: DIFFERENT SLICETYPES AND VARIANTS
We want specific ("registered") slice types, somehow reflected in
their suffixes. (Not specifying suffixes now.)
Main types (not needed immediately but important to think about):
- ZZ CELLSTRUCTURE (plain) (whether local or transmitted)
- USER'S LOCAL CELL DIVISIONS / PARTITIONS
- SHOWPACK / SCENEPACK / FLIGHT (fulfilled, hollow, par-filled)
- DOCUMENT (fulfilled, hollow, par-filled)
- DOCMOD, CHANGE (fulfilled, hollow, par-filled)
This will be represented as a hypertime modification
(position, string, op).
- CHAT, VOIP INCREMENT (fulfilled, hollow, par-filled)
- JABBER EQUIVALENT
Not literally, but we need something that implements the IDEA
of the Jabber protocol-- back-and-forth of cells and content.
- SCENE BUFFER for current scene
=SLICE NAMING AS A CROSS-PLATFORM ISSUE
Different OSs are different about capitalization!
Windows: A = a (you can't store Hello without replacing HELLO)
Unix, Linux, OSX: A does not equal a, every capital combination
is a different filename.
We can't have that. WE MUST ADOPT THIS CONVENTION: Slicenames are all
lower case and that's that.
(Unix will not accept spaces, except with special handling, so we
must avoid them.)
(Are there any other characters acceptable cross-platform?
Windows will accept a number of funny ANSI characters, but presumably
the others will not.)
=MULTIDOT SUFFIXES
All three platforms will accept multidot suffixes.
Presumably the last suffix will be a file type, on the Windows/DOS
model, since the others will not object. Three or four letters are
best.
=SLICENAME VERSIONING
Tentative:
name.version.slicetype
where "version" is an integer. The CURRENT version will have nothing
between the two dots.
>>>Should versioned slices have internal dates?
===SLICE TUPLES EXACTITUDE
Rob says it is important that a tuple maps unambiguously to a slice.
I do not understand this fully.
===BUFFERNAME VERSIONING
Screen buffer slices have an identity if saved. Screenbuffers will
have ascending counts in the names, if saved at all.
(Should they have internal dates?)
===SLICE BACKUP ISSUES
=OTHER DIRECTORIES
On the user's local machine there should be at least one backup
directory for saved slices, so that only active slices are seen in the
current directory.
===THE SCENELIST: misc. points
Scenelists are HARD TO EXPLAIN. Help is needed.
Note that SCENELIST HAS NO ORDER, objects may be anywhere
regardless of how they are ordered on scenelist.
Scenelists are composed of vunits, except where they also have a
camera position.
Hard to explain.
Perhaps some rethinking is needed.
=LOTS OF CHANGES NEEDED
We need to straighten scenelists out. PARTLY THIS IS A RENAMING PROBLEM.
Agreed: the list should be on d.2, as lists generally are.
=THE d.1 PROBLEM
We must rethink d.1, which has been overloaded. Currently d.1 is used
in scenelists for
- comments
- tetroids connected to their slab! (Contents of slab) [I didn't know]
- relative positioning with regard to another object (Rob's
initiative). As presently used, d.1 moves the vunit from an arbitrary
position. It may be possible to combine this with 'd.translate',
which moves the vunit from 0,0,0.
===SWORFING: THE PROBLEM OF SWORFING CONNECTION-LINES CORRECTLY
It turns out that Lukka doesn't sworf 'em in Gzz, he just fades them
out and redraws! Fooled me.
Rob wants to do better than Gzz on this. I say that's wonderful but
not topmost priority.
===MULTIPART CELL ADDRESSING ISSUE
Rob and I have had an ongoing discussion of what address parts a cell
should have. This is really about--
- whether the slice of creation matters
- where cells are going after they're created, and when and how
We want to be able to recognize (and address-- that is, ask for--) the
same cell no matter where it turns up.
We've decided on four fields--
- cellID, of course (an ascending integer)
- slice of origin
- username ("account")
- servername
I forget why we want slice of origin, but in any case it's been left
there, with the proviso that you don't have to ask for it-- you can
just ask for that user's cellID/slice/server.
=TRANSMISSION OF CELLS, POSSIBLY CONTENT
Our model is a centralized service with a common addressing structure.
And we want to make it possible for all cells to be recognized, no
matter where they have gotten to.
Some transport cells-- zzcells used to transport others-- may simply
be eradicated when they've done their job.
=ORIGINS OF "SERVER/SLICE/cellID"
This comes from the old Xanadu address (xu88), which identified all
contents (characters and links) as--
server / account / document / position
Transposing this division to ZigZag cells,
server,account,doct => Sharable content of cells with identified origins
For instance, a structured piece that fits into something else, such
as an editorial change in a document. That means that the origin of
each cell can be spotted and collaborations precisely sorted out.
="SLICE OF ORIGIN" IS NOT USUALLY A CONCEPT.
Each user's next cell is just the next cell, regardless of the slice
it goes into.
Slicenames of origin can be ignored and wild-carded; THAT MEANS you
can look for a given user's cell N on any slice, under the assumption
there are not two of the same ID.
=SENDING NAMED SLICES BETWEEN USERS
has been thought of as very unlikely. But then, they might do it
among themselves; or, this may turn out to be the way we package
documents up.
=CONNECTION OF SAME CELLS
For several years, it has been part of the design that for all slices
in RAM, instances of the same cell are connected-- prob. on dimension
'd.samecell' or the like.
===SCRIPTING
=WHEN CAN WE EDIT SCRIPTS AND SEE ZIGZAG RESULTS?
"Two or three days," says Rob.
=SCRIPTING ENHANCEMENT NOW IN PLACE
Scripts may be put in files
python1.txt... python5.txt
and run with function keys F1... F5.
=SCRIPTS IN CELLS
Scripts will be in cells. They will call each other, though the exact
mechanics are not decided.
===ZIGZAG VIEWS
=ZIGZAG VIEWS: TO SELECT A CELL AS REFRESH CENTER
cursor,index:fw.focus()
=ZIGZAG VIEWS: WHATCHAMACALLIT
On the current build,
Rob's horizontal XXX [26p21]
is under F1.
===OUR LANGUAGE, recently called "Gartersnake"
Functions are defined to be AS FORGIVING AS POSSIBLE, so nothing stops.
=MOST FUNCTIONS RETURN LISTS EXCEPT--
CELL returns a tuple
SLICE returns a tuple
zz.value returns a string
>>>What will we do when cells have other content types?
=THE MYSTERY OF PYTHON TUPLES, NOW SIMPLIFIED
Rob says he could use lists. But tuples AVOID MEDDLING.
He now allows
value,value,value
(value,value,value)
(tuple)
as equivalent inputs to a function.
=DIMDESIGNATORS (may become called "dimkeys")
The following are allowed:
(tuple) -- for dimdesignator cell
(dimname)
(-dimname)
(+dimname)
=NONEXISTENT DIMENSIONS
Trying to use a nonexistent dimension will cause an error.
>>PERHAPS THIS SHOULD BE CHANGED.
But
zz.dimdesignator(d.nonexistentdimension)
returns a zero.
=DIMENSION SYNONYMS
I pointed out to Rob that allowing dimensions to have more than one
name will allow tweaking dimension names without breaking the code.
He promises to think about it.
=PYTHON TRUTH-VALUES
Just for review: any value in Python is considered 'true' except
0
'false' (string)
'nothing' (string)
=CHANGES FROM ROB'S GARTERSNAKE WRITEUP (of 06.07.15)
=RINGRANK DETECTION
The function
zz.last()
detects a ringrank, in that it returns the same cell if it is
in a ringrank. HowEVer, that means the result would be the same if--
- there's only one cell
- there's only one cell but it's looped to itself, a very
different but important case
Rob will therefore put in the test
bool zz.isringrank(cell,dim)
to return true if ringrank, false if not.
===NAMING AND RENAMING ISSUES
We have many things to keep track of and communicate to our future
users. These need to be expressed in the best terms we can find.
This means continual reassessment of what terminology works best.
=TERMS NEEDED
We need a term for 'document change unit'-- both as sent between users
and as accumulated in the Hypertime edit list.
=BEST NAME FOR OUR SCRIPTING LANGUAGE?
Our little scripting language wraps C++ routines for calling by
Python. What call it?
"Gartersnake" is too obscure. Something more related to the aquatic
"FloatingWorld" could be good. For instance--
UNDERSEE
UNDERFLOW
UNDERWHERE
UNDERWORLD
FLOTATION
TRANSFLOTATION
I particularly like "underflow"-- which long ago meant a particular
computer condition, but here connotes that which is flowing under our
floating world.
=NEW TERM: "Outspread" for documents spread open in space-- open, set
up and broadly viewable. (The term "open" has many connotations in
the present document world-- open source, OpenDoc-- so we had best go
another way.)
=MAJOR NAMING OF PARTS
- 'Scenelist' may become 'Vunit List'
- 'Tetroid' may become 'string'
- SCENE may refer to a combinable part (e.g. a single document)
- SHOW may refer to a gathered combination of scenes, such as a
package of opened documents
- "permascroll" => SOURCE (in our Python functions)-- not all
sources are permascrolls
- dimdesignator may become 'dimkey'
- 'zz.createfollowing' should perhaps become 'zz.createalong'.
=SCENELIST DIMENSIONS-- RENAMING THEM, REALLOCATING THEM
d.1 for comment => d.comment or d.scenecomment
d.1 for tetroid => d.strings ? d.containedstrings?
=> d.flow?
=> d.docseq? /Rob doesn't like
d.1 for relative positioning
=> d.relativeposition
Could that somehow include relative from
0,0,0? Assimilate to d.translate?
d.represents => d.instantiate?
(This dimension allows multiple vunits to derive from the
same origin vunit.)
=THE STRANDCHUNK ISSUE
What Rob wants to call "strandchunk"
=> consecutive span of dereferenced strand
consecutive segment
unbroken span
[SEE PIC nbk06.07.26p74-5]
These are portions which are
- unbroken from their original locations
- unbroken by currently operative link endsets
These are to be successively divided and recombined during document
sessions, as part of TransLit internal data and buffer management.
Any re-use may chew them up further.
When we stop showing anything which divided such a segment (a
particular transclusion or link), the segments will be recombined.
>>>Rob wants a new celltype for these. I suggest--
- "consegment" (consecutive segment)
- "unbrokenspan".
The same transcluded span has two different indices, whether it is
- in the source document
- in a transcluding document
(Actually it has three indices--
- point within the span (same in either)
- point in the original source strand
- point in the destination strand
Thus, saith Rob, it should have two different names for referencing in
our scripting code. Fine with me, we just need to pick them. I would
suggest
- sourceUnbrokenspan
- destUnbrokenspan
but it's under discussion.
===ISSUES UNRESOLVED
=(HYPERTIME FOR ZIGZAG UNDO etc)
We know we want hypertime editing for documents.
The same thing for ZigZag is an open issue. I think it is the best
way to do versioning, but we have a lot of loose directions here.
=AUDIO
Rob: "To do audio properly... The more I think about it, the simpler
it should be..."
An audio library has two buffers-- one being played, one filling up.
[I presume that's for each track or strand.]
We leave this for the future.
=LINK-LOCKS
These were an important part of the 1980s design. Currently being
Thought About.
=VINKS
Vinks go way back in ZigZag history, eg for Polish Notation executable
[pic nbk06.07.27p8].
Whether to include them soon is a question.
=CAPS-LOCK TIMEOUT
Very desirable.
===GLOSSARY FOR THIS DOCUMENT
comparison strip
set of consecutive cells +d.2 in the keyboard filter, to be
compared to an incoming keystroke.
contact shoe
cell connected to cell for a "contact" ZigZag function.
hovering function
function accomplished without an actual ZigZag connection or contact shoe.
hypercap
new special alphabet made possible by Keyboard Filter.
local clone
clone which is not a remote clone; plain clone.
operative clink, currently operative clink
a clink which is presently recognized as in place on a document.
outspread document
document spread open in space-- open, set up and viewable, with
links and transclusions turnable on and off.
package
a slice set up with specific pieces, portions or sections inside.
plain clone
clone which is not a remote clone; local clone.
posture, document posture
how a document is arranged and shown.
rollup, script rollup
freezing scripts into a compiled version (method undecided) so
they are user-inaccessible. This will have to be done repeatedly.
show
a gathered combination of scenes, such as a package of opened documents.
slice (official definition)
a collection of cells and possibly content, either for local use
or transmission.
strand
a sequential part of a translit document.
transport cells
zzcells used to transport others. These may simply be eradicated
when they've done their job.
typetweak
function of the keyboard filter that changes an input string. It
may either have a preset string to output or create something more
intricate.
wheelhandle
a cell attached negward from a wheel, providing access to the
wheel; may be used to demarcate a section, such as a comparison strip.
—30•–
span: