[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[ff-cvs] libvob/doc/pegboard/animation_api--mudyc peg.rst

From: Matti Katila
Subject: [ff-cvs] libvob/doc/pegboard/animation_api--mudyc peg.rst
Date: Wed, 15 Oct 2003 05:22:37 -0400

CVSROOT:        /cvsroot/libvob
Module name:    libvob
Changes by:     Matti Katila <address@hidden>   03/10/15 05:22:37

Modified files:
        doc/pegboard/animation_api--mudyc: peg.rst 

Log message:
        current peg


Index: libvob/doc/pegboard/animation_api--mudyc/peg.rst
diff -u libvob/doc/pegboard/animation_api--mudyc/peg.rst:1.5 
--- libvob/doc/pegboard/animation_api--mudyc/peg.rst:1.5        Fri Oct 10 
14:15:15 2003
+++ libvob/doc/pegboard/animation_api--mudyc/peg.rst    Wed Oct 15 05:22:36 2003
@@ -5,10 +5,10 @@
 :Authors:  mudyc
 :Date-Created: 2003-09-27
-:Last-Modified: $Date: 2003/10/10 18:15:15 $
-:Revision: $Revision: 1.5 $
-:Status:   Incomplete
-:Stakeholders: mudyc, tjl, benja, humppake
+:Last-Modified: $Date: 2003/10/15 09:22:36 $
+:Revision: $Revision: 1.6 $
+:Status:   Current
+:Stakeholders: mudyc, tjl, benja
 :Scope:    Minor
 :Type:     Policy, Interface
@@ -26,7 +26,7 @@
 directly, let us have a new API which is told the caller of ``chg``,
 for debugging::
-    anim.chgAnimate("MouseEventHdl");
+    anim.animate("MouseEventHdl");
 where ``anim`` is an instance of ``AnimationAPI``.
@@ -42,47 +42,26 @@
    this is easy to convert as a simple test.
-ISSUE: What about requesting a longer or shorter animation time, 
-or a non-standard animation curve (i.e. linear instead of the 
-vibrating exponential)?
-Should this be covered by the animation API or bypassed to 
-AbstractUpdateManager? If there's a particular change that 
-should happen with a faster animation time (e.g. a menu closing)
-    RESOLVED: Later. It's easy to add this feature into AnimationAPI:
-        a) when we know issues with it, 
-        b) we have prototype of it and
-        c) we have used the prototype in real program.
-    All features in this peg are here because they are used in real 
-    programs and them are well known already.
 ISSUE: If we don't want people to see AbstractUpdateManager
-should we hide some of its methods to package private?
+should we hide some of it's methods to package private?
     Small demos might still need these methods.
-    Otoh, the safer the better. 
-ISSUE: Should the default be to animate or not to animate?
-    RESOLVED: chg() without update method set should throw an error.
-    Explicity is better and it makes code cleaner somehow.
+    Otoh, safer is better. One possibility is to 
+    add this API with in demo framework but then it would be
+    very hard to call from java side.
 Create a new animation layer which encapsulates 
-AbstractUpdateManager method calls, i.e, chg() and setNoAnimation().
+AbstractUpdateManager method calls, i.e, chg and setNoAnimation.
 The new layer will be the only one that takes care of reusing VobScenes.
-**No other objects are allowed to call the UpdateManager methods in 
-the source tree, except small demos.**
-XXX Sometimes when regeneratingVS, you need to be sure that 
-update has happen!
-    - Can new event be handler before new VobScene is created?!
+**No other objects are allowed to call the above named UpdateManager 
+methods in the source tree, except small demos.**
+For safety of event handling, possibility to check if 
+VobScene has changed is added into the animation layer.
 Let's define the following interface: ::
@@ -92,7 +71,7 @@
     /** An interface for providing common tool set for animation 
      * and animation debugging information.
      * This interface encapsulates the low-level animation interface
-     * such as AbstractUpdateManager methods. 
+     * such as AbstractUpdateManagers' chg and setNoAnimation methods. 
      * <p>
      * This interface set strict policy for several routines.
@@ -112,18 +91,28 @@
         /** Animate to next VobScene by creating a new VobScene.
-        void animate();
+        void animate(String caller);
         /** Switch to next VobScene by creating a new VobScene.
          * The switch is fast and no animation is seen.
-        void switchVS();
+        void switchVS(String caller);
-        /** Rerender the current VobScene.
+        /** Rerender the current VobScene. 
+         * Changes in next frame is seen if coordinate system
+         * parameters are set. Rerendering current VobScene 
+         * is much faster than creating a new VobScene, 
+         * so e.g., any drag actions should be implemented to use
+         * this method. 
+        * <p>
+         * Even new coordinate systems can be created, the current 
+         * coorder implementation uses finite range of coordinate systems, 
+        * and creating too many new coordinate systems leads to
+         * undefined behauviour.
-        void rerender();
+        void rerender(String caller);
        /** Get the current visible vobscene. 
@@ -133,6 +122,13 @@
         VobScene getCurrentVS();
+       /** Returns true if VobScene has changed from previous
+         * <code> animate</code> or <code>switchVS</code> method.
+         * In some situations when handling the events programmer 
+         * need to know whether the VobScene is new or the still the old one.
+        */
+       boolean hasVSchanged();

reply via email to

[Prev in Thread] Current Thread [Next in Thread]