[Gzz-commits] manuscripts/FutureVision vision.rst

[Tuomas J. Lukka]

CVSROOT:        /cvsroot/gzz
Module name:    manuscripts
Branch:         
Changes by:     Tuomas J. Lukka <address@hidden>        03/09/18 05:04:44

Modified files:
        FutureVision   : vision.rst 

Log message:
        libvob

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/manuscripts/FutureVision/vision.rst.diff?tr1=1.56&tr2=1.57&r1=text&r2=text

Patches:
Index: manuscripts/FutureVision/vision.rst
diff -u manuscripts/FutureVision/vision.rst:1.56 
manuscripts/FutureVision/vision.rst:1.57
--- manuscripts/FutureVision/vision.rst:1.56    Thu Sep 18 04:48:53 2003
+++ manuscripts/FutureVision/vision.rst Thu Sep 18 05:04:44 2003
@@ -265,23 +265,57 @@
 ===================
 
 Fenfire is a free software project aiming at implementing
-the user interface concepts on top of an RDF graph,
+the applitude-oriented user interface concepts on top of an RDF graph.
+
+Fenfire is, against some trends, a relatively monolithic system -
+to be able to XXX we have to simultaneously replace the 
+backend structure and the user-interface framework.
+
+
+
+Fenfire structures are defined by simple RDF vocabularies,
 
-Fenfire structures are defined by as simple RDF vocabularies as possible
 
     - implemented separately by classes
 
-    - intent: combine into applitudes, have metadata
+    - intent: combine into applitudes, have metadata of the 
+      structures also in RDF
 
-Free software
+    - possibly at a later date use ontologies and schemas
+      &c to allow
+      flexible definition of applitudes
 
-    - situation in the software market is such that it's not likely
-      a new type of product could succeed commercially. 
 
 Libvob
 ------
 
-- keys, structures allow "annotations"
+Libvob is a subproject of Fenfire, providing a flexible user-interface
+toolkit with some novel features that allow the independent
+applitudes to work on the same user interface.
+
+Instead of a static structure of widgets or a scene graph,
+the scene is regenerated each time the user presses a key [#libvob-speed]_.
+
+The scene consists of a DAG of coordinate systems (the actual
+coordinate systems), a keyed tree for *identifying* coordinate
+systems and a set of renderable objects (vobs) placed into 
+one or more coordinate systems each.
+
+This structure allows
+
+1) Automatically generated animations between successively 
+   generated scenes: the coordinate systems are matched
+   to each other based on the keyed tree and sometimes special
+   instructions
+
+2) More importantly, **post-processing** of the view generated
+   by other applitudes -- applitudes can **add** new coordinate
+   systems and vobs on the view, based on what is already shown.
+
+   The buoys are added this way: a connector object goes through
+   a generated vobscene and adds buoys to the nodes in it - regardless
+   of who placed those nodes in there.
+
 
 
 An example applitude combining multiple structures: FenPDF
@@ -298,7 +332,8 @@
 
 - fluid links
 
-
+The implementation is currently flexible; new types of 
+structures can be added easily.
 
 Related work
 ============
@@ -386,6 +421,11 @@
 
     - working FenPDF system
 
+Free software
+
+    - situation in the software market is such that it's not likely
+      a new type of product could succeed commercially. 
+
 Acknowledgments
 ===============
 
@@ -606,6 +646,16 @@
 .. [#zzstructure] zzStructure is the "generic term" Nelson
    recommends for discussing the structure used in ZigZag(TM),
    (Nelson's trademark).
+
+..  [#libvob-speed] For some changes (panning, zooming), the scene
+    need not be regenerated but only the coordinate system 
+    parameters adjusted.
+
+    Also, scene regeneration is not necessarily slow: we have
+    some extremely promising results
+    functional programming -related 
+    caching techniques and are experimenting with recursive vobscenes
+    in that context.