[Gzz-commits] gzz/doc/pegboard/1005 PEG_1005.txt

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      02/09/24 08:42:29

Modified files:
        doc/pegboard/1005: PEG_1005.txt 

Log message:
        comment

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1005/PEG_1005.txt.diff?tr1=1.1&tr2=1.2&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/1005/PEG_1005.txt
diff -c gzz/doc/pegboard/1005/PEG_1005.txt:1.1 
gzz/doc/pegboard/1005/PEG_1005.txt:1.2
*** gzz/doc/pegboard/1005/PEG_1005.txt:1.1      Thu Sep 12 09:04:03 2002
--- gzz/doc/pegboard/1005/PEG_1005.txt  Tue Sep 24 08:42:29 2002
***************
*** 2,22 ****
  
  Subject: One more split of VobScene
  
! Currently, a VobScene consists of 
  1) VobMap: the binding between coordinate systems indices and vobs,
  2) VobCoorder: the coordinate systems and their keys
  
  I'm suggesting splitting this one more time:
  1) VobMap: the binding between coordinate systems indices and vobs,
! 2) VobCoorder: the coordinate systems 
  3) VobMatcher: the binding between coordinate system indices and keys.
  
  GraphicsAPI calls creating vobscenes would accept a parameter for VobMatcher 
for now,
  or alternatively it would not yet be a final member.
  
  The point is to free the vob matching functionality for extending and 
experiments;
  we want hierarchical things, things depending not only on identity but clicks 
etc.
  
  The VobMatcher API would be
  
      public interface VobMatcher {
--- 2,29 ----
  
  Subject: One more split of VobScene
  
! Currently, a VobScene consists of
  1) VobMap: the binding between coordinate systems indices and vobs,
  2) VobCoorder: the coordinate systems and their keys
  
  I'm suggesting splitting this one more time:
  1) VobMap: the binding between coordinate systems indices and vobs,
! 2) VobCoorder: the coordinate systems
  3) VobMatcher: the binding between coordinate system indices and keys.
  
  GraphicsAPI calls creating vobscenes would accept a parameter for VobMatcher 
for now,
  or alternatively it would not yet be a final member.
  
+ (Benja:)
+      Sounds ok.
+ 
  The point is to free the vob matching functionality for extending and 
experiments;
  we want hierarchical things, things depending not only on identity but clicks 
etc.
  
+ (Benja:)
+     Not sure we can make it general enough to encompass all the experiments
+     we'd like to do...
+ 
  The VobMatcher API would be
  
      public interface VobMatcher {
***************
*** 34,39 ****
--- 41,57 ----
  Now, the important point is that particular vobmatchers can add other add 
methods, e.g.
  
        void add(int cs, Object key, String subkey)
+       
+ (Benja:)
+     One thing I would like to do is span interpolation similar to the old text
+     interpolation stuff from 0.6. So,
+ 
+         void add(int cs, Object key, int start, int n)
+ 
+     But that needs help from the coorder or somewhere to work right,
+     because it may need to split the spans while interpolating...
+     
+     Can that work with this scheme?`
  
  
  At the same time, add to VobMap a new method
***************
*** 41,45 ****
--- 59,67 ----
      put(Vob v)
  
  without a coordinate system, for non-coorded vobs.
+ 
+ (Benja:) 
+     I'd prefer a longer (more descriptive) method name as this won't be used 
+     as often.
  
      Tuomas