7 |
:Date-Created: 2003-09-27 |
:Date-Created: 2003-09-27 |
8 |
:Last-Modified: $Date$ |
:Last-Modified: $Date$ |
9 |
:Revision: $Revision$ |
:Revision: $Revision$ |
10 |
:Status: Incomplete |
:Status: Current |
11 |
:Stakeholders: mudyc, tjl, benja, humppake |
:Stakeholders: mudyc, tjl, benja |
12 |
:Scope: Minor |
:Scope: Minor |
13 |
:Type: Policy, Interface |
:Type: Policy, Interface |
14 |
|
|
26 |
directly, let us have a new API which is told the caller of ``chg``, |
directly, let us have a new API which is told the caller of ``chg``, |
27 |
for debugging:: |
for debugging:: |
28 |
|
|
29 |
anim.chgAnimate("MouseEventHdl"); |
anim.animate("MouseEventHdl"); |
30 |
|
|
31 |
where ``anim`` is an instance of ``AnimationAPI``. |
where ``anim`` is an instance of ``AnimationAPI``. |
32 |
|
|
42 |
this is easy to convert as a simple test. |
this is easy to convert as a simple test. |
43 |
|
|
44 |
|
|
|
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. |
|
|
|
|
|
|
|
45 |
ISSUE: If we don't want people to see AbstractUpdateManager |
ISSUE: If we don't want people to see AbstractUpdateManager |
46 |
should we hide some of its methods to package private? |
should we hide some of it's methods to package private? |
47 |
|
|
48 |
Small demos might still need these methods. |
Small demos might still need these methods. |
49 |
Otoh, the safer the better. |
Otoh, safer is better. One possibility is to |
50 |
|
add this API with in demo framework but then it would be |
51 |
ISSUE: Should the default be to animate or not to animate? |
very hard to call from java side. |
|
|
|
|
RESOLVED: chg() without update method set should throw an error. |
|
|
Explicity is better and it makes code cleaner somehow. |
|
52 |
|
|
53 |
|
|
54 |
Changes |
Changes |
55 |
======= |
======= |
56 |
|
|
57 |
Create a new animation layer which encapsulates |
Create a new animation layer which encapsulates |
58 |
AbstractUpdateManager method calls, i.e, chg() and setNoAnimation(). |
AbstractUpdateManager method calls, i.e, chg and setNoAnimation. |
59 |
The new layer will be the only one that takes care of reusing VobScenes. |
The new layer will be the only one that takes care of reusing VobScenes. |
60 |
**No other objects are allowed to call the UpdateManager methods in |
**No other objects are allowed to call the above named UpdateManager |
61 |
the source tree, except small demos.** |
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?! |
|
62 |
|
|
63 |
|
For safety of event handling, possibility to check if |
64 |
|
VobScene has changed is added into the animation layer. |
65 |
|
|
66 |
Let's define the following interface: :: |
Let's define the following interface: :: |
67 |
|
|
71 |
/** An interface for providing common tool set for animation |
/** An interface for providing common tool set for animation |
72 |
* and animation debugging information. |
* and animation debugging information. |
73 |
* This interface encapsulates the low-level animation interface |
* This interface encapsulates the low-level animation interface |
74 |
* such as AbstractUpdateManager methods. |
* such as AbstractUpdateManagers' chg and setNoAnimation methods. |
75 |
* <p> |
* <p> |
76 |
* This interface set strict policy for several routines. |
* This interface set strict policy for several routines. |
77 |
* |
* |
91 |
|
|
92 |
/** Animate to next VobScene by creating a new VobScene. |
/** Animate to next VobScene by creating a new VobScene. |
93 |
*/ |
*/ |
94 |
void animate(); |
void animate(String caller); |
95 |
|
|
96 |
|
|
97 |
/** Switch to next VobScene by creating a new VobScene. |
/** Switch to next VobScene by creating a new VobScene. |
98 |
* The switch is fast and no animation is seen. |
* The switch is fast and no animation is seen. |
99 |
*/ |
*/ |
100 |
void switchVS(); |
void switchVS(String caller); |
101 |
|
|
102 |
|
|
103 |
/** Rerender the current VobScene. |
/** Rerender the current VobScene. |
104 |
|
* Changes in next frame is seen if coordinate system |
105 |
|
* parameters are set. Rerendering current VobScene |
106 |
|
* is much faster than creating a new VobScene, |
107 |
|
* so e.g., any drag actions should be implemented to use |
108 |
|
* this method. |
109 |
|
* <p> |
110 |
|
* Even new coordinate systems can be created, the current |
111 |
|
* coorder implementation uses finite range of coordinate systems, |
112 |
|
* and creating too many new coordinate systems leads to |
113 |
|
* undefined behauviour. |
114 |
*/ |
*/ |
115 |
void rerender(); |
void rerender(String caller); |
116 |
|
|
117 |
|
|
118 |
/** Get the current visible vobscene. |
/** Get the current visible vobscene. |
122 |
*/ |
*/ |
123 |
VobScene getCurrentVS(); |
VobScene getCurrentVS(); |
124 |
|
|
125 |
|
|
126 |
|
/** Returns true if VobScene has changed from previous |
127 |
|
* <code> animate</code> or <code>switchVS</code> method. |
128 |
|
* In some situations when handling the events programmer |
129 |
|
* need to know whether the VobScene is new or the still the old one. |
130 |
|
*/ |
131 |
|
boolean hasVSchanged(); |
132 |
} |
} |
133 |
|
|
134 |
|
|