[Gzz-commits] gzz/doc/pegboard/1009 PEG_1009.rst

[Benja Fallenstein]

CVSROOT:        /cvsroot/gzz
Module name:    gzz
Changes by:     Benja Fallenstein <address@hidden>      02/10/06 12:52:16

Modified files:
        doc/pegboard/1009: PEG_1009.rst 

Log message:
        comment

CVSWeb URLs:
http://savannah.gnu.org/cgi-bin/viewcvs/gzz/gzz/doc/pegboard/1009/PEG_1009.rst.diff?tr1=1.7&tr2=1.8&r1=text&r2=text

Patches:
Index: gzz/doc/pegboard/1009/PEG_1009.rst
diff -c gzz/doc/pegboard/1009/PEG_1009.rst:1.7 
gzz/doc/pegboard/1009/PEG_1009.rst:1.8
*** gzz/doc/pegboard/1009/PEG_1009.rst:1.7      Sun Oct  6 12:44:05 2002
--- gzz/doc/pegboard/1009/PEG_1009.rst  Sun Oct  6 12:52:16 2002
***************
*** 4,11 ****
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/06 16:44:05 $
! :Revision: $Revision: 1.7 $
  :Status:   Incomplete
  
  Transformations
--- 4,11 ----
  =============================================================
  
  :Authors:  Tuomas Lukka
! :Date:     $Date: 2002/10/06 16:52:16 $
! :Revision: $Revision: 1.8 $
  :Status:   Incomplete
  
  Transformations
***************
*** 34,44 ****
        
        (Tjl:) Well, coordsys already *does* scale. The thing is to just
        ask for the font's width with the right scale, which you should
!       be able to ask the coordsys. Something like 
  
            scale = vs.getHeight(cs);
  
        ?
  
  And into AffineVobCoorder the following functions::
  
--- 34,48 ----
        
        (Tjl:) Well, coordsys already *does* scale. The thing is to just
        ask for the font's width with the right scale, which you should
!       be able to ask the coordsys. Something like ::
  
            scale = vs.getHeight(cs);
  
        ?
+         
+             (Benja:) We have talked about this earlier. It messes up the
+             layout, because *the aspect ratio changes*, as I have said above.
+             You *cannot* assume that you can scale below the view level in 
AWT.
  
  And into AffineVobCoorder the following functions::
  
***************
*** 60,65 ****
--- 64,71 ----
        (Tjl:) Well, have you looked at fillets demo? We don't always
        want to keep in a 2 1/2 D world. Sometimes 3D is nice.
        But maybe best to leave it to GLVobCoorder.
+         
+             (Benja:) Ok.
  
  Also, for all these functions, we should have a shorthand
  in VobScene:
***************
*** 71,76 ****
--- 77,84 ----
      (Benja:) How about just ``translate``?
        
        (Tjl:) Want to make sure it's not interpreted as "translate this 
vobscene".
+         
+             (Benja:) Hmmm... ok... ``translateCS`` just seems hard to write.
  
  For the affine ones, the VobCoorder is cast into AffineVobCoorder, and
  the error propagated if it's not.
***************
*** 87,92 ****
--- 95,104 ----
  
        (Tjl:) How about UnsupportedOperationException? Hmm..
        or a subclass of that, NotAffineCoorder
+         
+             (Benja:) Subclass, because a) we need to store the view in
+             the exception, and b) ``UnsupportedOperationException`` is
+             raised by *many* things, not safe to use at all.
  
  
  Transforming points into coordinate systems
***************
*** 116,121 ****
--- 128,139 ----
        (Tjl:) One that requires catch() or one that doesn't?
        I don't really like the exception either way: a pseudoinverse
        (closest to real inverse) can be well-defined.
+         
+             (Benja:) Hm. So is the method supposed to return ``true``
+             if the inverse that was found is real? Then need to change
+             javadoc: a pseudoinverse is "reasonable" IMHO. On the other
+             hand, if there are cases where no usable inverse can be found,
+             we need the exception (not sure which type).
  
  The reason for allowing the array ``pt[]`` to contain several points is
  simply performance.