476 |
Implementation on the Gzz platform |
Implementation on the Gzz platform |
477 |
================================== |
================================== |
478 |
|
|
479 |
The implementation of the link structure and the above visual tenchiques |
The Gzz platform supports easy prototyping of the above link structure and |
480 |
is easy on the Gzz platform because of several features. |
visual tenchiques because of several features. |
481 |
|
|
482 |
First, the Xanadu[XXX] structure implemented on Gzz |
First, the Gzz storage model (Storm[XXX]) provides globally unique |
483 |
provides a way for specifying associations between parts |
identities for the documents and structural nodes and |
484 |
of documents. Furthermore ... |
the Xanadu[XXX] structure implemented on Gzz is a convenient way |
485 |
XXXidentity??? |
for specifying associations between parts of documents. |
486 |
|
|
487 |
Second, the Gzz view model provides a simple way of |
Second, the Gzz view model provides a simple way of |
488 |
specifying geometry and automatic animation between views. |
specifying geometry and automatic animation between views. |
489 |
|
A view contains coordinate systems and vobs. |
490 |
A view, or a vobscene, contains coordinate systems and vobs. |
Vob is a visual object that knows how to draw itself in |
491 |
Vob is a "visual object" that knows how to draw itself using zero, |
one or more coordinate systems (for example, a connection line |
492 |
one, or more coordinate systems. For example, a text string |
vob draws a line between the origins of two coordinate systems). |
493 |
drawn starting at the unit square of a text coordinate system or |
When the user moves from one view to another, |
494 |
a connection line drawn between the origins of two coordinate systems. |
the coordinate systems of the first view are |
495 |
The reason for separate coordinate systems is that a scene |
interpolated to the matching coordinate systems of the |
496 |
can be animated by interpolating the coordinate systems. |
following scene, resulting in smooth animation. |
497 |
|
|
498 |
The coordinate systems can be recursive so that one coordinate |
Third, most source code changes yield immediate effect without rebuilding. |
499 |
system is specified depending on another coordninate system. |
Jython source files can be dynamically reloaded and most vobs |
500 |
For example, the buoy coordinate system uses a transformation |
are specified using a string that is dynamically compiled into an |
501 |
from the anchor position to the buoy position on a circle using |
OpenGL display list. |
502 |
the origin of the focus coordinate system. |
Despite this, the framerate is high, because the |
|
|
|
|
Each coordinate system has an identifier and a parent coordinate |
|
|
system. When the user moves from one view to another, |
|
|
the coordinate systems of the two vobscenes are matched. |
|
|
Matching coordinate systems (with matching parents) are smoothly |
|
|
interpolated resulting in smooth animation from an object in one |
|
|
scene to the corresponding object in the other scene. |
|
|
If an object only exists in one of the scenes, it appears or |
|
|
disappears at the middle point of the animation. |
|
|
|
|
|
Another important feature is the dynamic object model. |
|
|
Jython source files can be dynamically reloaded, and many |
|
|
vobs can be specified simply as a string that is dynamically |
|
|
compiled to an OpenGL display list. |
|
|
Despite the dynamic nature, the code runs fast, because the |
|
503 |
interpolation of coordinate systems and the actual rendering of vobs |
interpolation of coordinate systems and the actual rendering of vobs |
504 |
is performed by native C++ code. |
is finally performed by native C++ code. |
505 |
|
|
506 |
|
|
507 |
An example structure: a MEMEX-like view of recent hypertext and graphics articles |
An example structure: a MEMEX-like view of recent hypertext and graphics articles |