xuspDemoTech-D8
=== 12.02.24
TECHNICALITIES OF THE XANADUSPACEô PACKAGE
Theodor Holm Nelson, Founding Designer, Project Xanadu
© 2012 Project Xanadu.
TRADEMARKS. XanaduÆ and ZigZagÆ are registered software trademarks of Project Xanadu. XanaduSpaceô, Xanadeskô and Xanaduleô are claimed trademarks of Project Xanadu.
XanaduSpace is intended to present a generalized flying connected literature. In fact, XanaduSpace is a fairly complete implementation of the Xanadu algorithms (as described in Xanasimp-Dx and elsewhere).
But there have been delays in getting out this generalized product.
The original programmer, Rob Smith, did a beautiful job and followed the specs; all levels of the system are carried out. But his deliverable shrank down to a demo for only Windows. Rob got brain-freeze and was unable to continue. The system remains incomplete.
We are still trying to make it a product (especally John Ohno and Jonathan Kopetz in Connecticut). However, that is a tough job because of the several levels to be disentangled.
=== WHAT IT SHOWS
There are many XanaduSpace builds with many visualizations; we are distributing the one that makes a particular point.
It is intended to answer the question: "How can you find your way through many overlapping connections?"
The answer is: "One at a time."
Accordingly, you may step among the eleven pages of this xanadoc, and step one-at-a-time through its twenty-six connections.
That's it.
=== PARADOX OF THE DEMO
The demo actually shows two contradictory things:
- a multipage xanadoc
- the origins of quotations in their original contexts
HOWEVER, the original sources have been truncated and put into the package. While they impersonate the original external context documents, they have been packaged up inside it. This is a misleading shortcut that conflates the two different ideas-- multiple pages and original contexts. If you have gotten this far, we hope you will understand and forgive this peccadillo. Mea culpa.
=== WHAT IT ENACTS UNDERNEATH: THE FULL XANADU METHOD
The XanaduSpace program actually steps through the entire Xanadu process. (Since all data is in the package, some levels are incomplete.)
1. Finding the content pointed to by the Edit Decision List (simulated-- the content is actually in the package)
2. Concatenating the content
3. Typesetting the content and dividing it into pages
4. Setting up the transclusion beams, finding identities by address
5. Applying the xanalinks to the pages (they don't show so well)
6. Showing the pages and connections.
7. User exploration, stepping among pages with sworfing (swooping + morphing).
=== QUIRKS OF THE PACKAGING
The system is supposed to accept new EDLs (content lists) and ODLs (overlay lists) from outside, and fetch stabilized, unchangeable content from the net.
In fact it is inside-out. Our EDL and ODL ended up hard-coded, and the "unchangeable" content is the only thing the user can change (inside a subdirectory called "demo" inside a subdirectory called "texts").
These are quirks of the last-minute wrapping and not traits of the XanaduSpace package.
=== === === BASIC INTERNAL SIMPLICITY
For internal simplicity, the system is built on ZigZag, a data system of multidimensional lists that is conceptually simple and efficient. In the Xanaduspace internals, zzcells represent all data units and spatial coordinates.
The XanaduSpace program has proven ZigZag as a data backbone. ZigZag speeded prototyping by its convenient spatial structure and easy connectability.
ZigZag also made the OpenGL 3D system simpler to use, by representing every 3D scene in zzcells. This means that a 3D scene can in principle be assembled by external scripts, or by hand.
=== === === INTERNAL LEVELS
Despite that conceptual simplicity, the XanaduSpace code has a lot of levels:
- C++ (for the parts that have to run very fast)
- Python (for the parts that are supposed to be scriptable)
- OpenGL (for the fast 3D mechanisms)
- ZigZag for the internal data mechanisms (lists in arbitrary dimensions)
- zzogl (a glue level between ZigZag and OpenGL, allowing a 3D scene to be built as a system of zzcells)
However, the demo shows that they work together well.
=== === === DEVELOPER MENU (only useful for getting to ZigZag)
There is a hidden menu you can get to by hitting ESCAPE.
This takes you to a curious internal developer menu which the programmer intended for his own use (so we can't complain about it). To step through this you use "c" and "e", but to select one you must click once with the mouse.
ZigZag is the first item (see below)
The others are not of much interest--
- Xanadu Space (origin) [back to scene]
- Xanadu Space (edit) [back to scene]
- Test [some editing test]
- Test2 [appears to freeze the system]
- Scribble [a drawing program of some sort]
=== === === ZIGZAG LEVEL
When you click on "ZigZag" in the developer menu,
you get a two-window view of actual cells of the scene,
like the standard view in ZigZag-gzz (see ZigZag
starter kit at xanadu.com/zigzag).
However, It is difficult to recognize the two windows
because they have no frames and it all looks like
one big scene. A hint as to the window boundaries
are the little block constructions floating above
separately, one for each window area, saying what
dimensions are currently visible, like the compasses
in the corners of the Gzz windows.
The flyaround commands are the same as in
xanaduspace--
- left arrow, right arrow (fly sideways)
- up arrow, down arrow (forward and back)
- right mousedown & move mouse (turn camera
and direction of flight)
In addition, some of the regular ZigZag commands
(KBLANG) work (again, see ZigZag starter kit)--
e,a,f,c move left cursor (blue)
i,j,l,(,) move right cursor (green)
(Unfortunately, for those who are used to standard
ZigZag, the colors of the two cursors are reversed
from the standard.)
/ (connect) works with the different directions.
h, H (hop) appear to work, but in nonstandard ways.
Not appearing to work from standard Kblang:
v, V step to next view in right window, left window
x,y,z step to next dimension on x, y or z axis of right window
X,Y,Z step to next dimension on x, y or z axis of left window
We encourage those wishing to explore.
=== === === INTERNAL PROBLEMS
Here is what our boys have found so far:
The ZigZag, zzogl and OpenGL levels of implementation appear to work without a hitch.
Some of the Python was embedded in the C++, which seemed like a good idea at the time but probably is not.
The C++ appears to be sound, but some of it (including the purpose-built C++ storage allocator) is not compatible with standard compilers.
Much of the Python scripting is good, though there are synchronization problems among the Python scripts and with the C++.
Further technical issues are being pried apart.
=30=
span: