24 |
.. contents:: |
.. contents:: |
25 |
|
|
26 |
|
|
27 |
|
|
28 |
|
------------------------- |
29 |
|
History of the vob system |
30 |
|
------------------------- |
31 |
|
|
32 |
|
|
33 |
First stage: The 0.6 system |
First stage: The 0.6 system |
34 |
=========================== |
=========================== |
35 |
|
|
82 |
``Object`` is created statically in some class and used |
``Object`` is created statically in some class and used |
83 |
as the key whenever a vob is placed into a scene in that role. |
as the key whenever a vob is placed into a scene in that role. |
84 |
|
|
85 |
This is somewhat ugly, but arguably not much less so than alternatives |
This is somewhat ugly, but arguably less so than alternatives |
86 |
(like the "vob path" hack, which bears some resemblance |
(like the "vob path" hack, which bears some resemblance |
87 |
to the role key phenomenon). |
to the role key phenomenon). |
88 |
|
|
90 |
Second stage: Coordinate systems |
Second stage: Coordinate systems |
91 |
================================ |
================================ |
92 |
|
|
93 |
In the second stage, invented by Tuomas in Spring 2002, modified |
The second stage, introduced by Tuomas in Spring 2002, modified |
94 |
the system by introducing *coordinate systems*. A coordinate system |
the system by introducing *coordinate systems*. A coordinate system |
95 |
is defined by a coordinate transformation (translation and scale |
is defined by a coordinate transformation (translation and scale |
96 |
or possibly a full affine transformation) relative to the canvas. |
or possibly a full affine transformation) relative to the canvas. |
97 |
It is coordinate systems that take identities (keys) in this system, |
It is coordinate systems that take identities (keys) in this system, |
98 |
not vobs. A vob is placed in one or more coordinate systems; |
not vobs. |
99 |
cell vobs are placed in a single coordsys, connection vobs are |
|
100 |
placed between the two coordinate systems they connect. |
Because coordinate systems have identities and are interpolated |
101 |
This system allowed the practical integration of connections |
between keyframes, vobs are now less overloaded: they can now be seen as |
102 |
into the vob system proper. |
graphical objects to be drawn in a coordinate system. |
103 |
|
|
104 |
In this system, vobs do not necessarily represent |
The most important effect of this change is that it allows |
105 |
an object with an identity; those showing cells do, those |
a single Vob to span two coordinate systems. The earlier system |
106 |
showing connections don't (these vobs represent the relation |
allowed animation of connections between vobs only in a kludgy |
107 |
between two different identities). Probably it can be said |
way. The new system allows the connection vob to know both |
108 |
that some vobs in this pattern represent objects with |
its start and end coordinate system and trivially draw itself |
109 |
identity; these vobs fill the corresponding coordsys with content |
from point A in coordsys 1 to point B in coordsys 2. |
110 |
(for example, the cell vobs fill the coordsys for that cell). |
|
111 |
Other vobs represent annotations to these objects; these do |
However, while a vob is now just a graphical object without identity, |
112 |
not fill a coordsys, but draw over or near to it |
some vobs are still drawn to show an object with identity, while |
113 |
(for example the connections, but possibly also a vob |
others are drawn as 'decorations' showing additional information |
114 |
that shows a little icon right next to a cell to indicate |
about those objects. For example, a vob that shows a cell |
115 |
something about the cell). |
is drawn to represent that cell to the user, while a vob showing |
116 |
|
a little icon next to the cell (to indicate it is has changed recently, |
117 |
|
say) does not represent the cell itself to the user, but |
118 |
|
additional information about the cell (even though both |
119 |
|
may be placed into the same coordinate system, keyed by the cell). |
120 |
|
|
121 |
It is still basically assumed in this system that there |
It is still basically assumed in this system that there |
122 |
is a set of identities, and each coordsys represents one member |
is a set of identities, and each coordsys represents one member |
154 |
in the middle" works in a different way. We use role |
in the middle" works in a different way. We use role |
155 |
keys to represent this kind of thing. |
keys to represent this kind of thing. |
156 |
|
|
157 |
(Note: A coordsys c1 inside coordsys p1 is interpolated |
[XXX Say something about interpolation hierarchies here? |
158 |
to c2 inside p2 if the keys of c1 and c2 are equal, and if |
Maybe leave as a detail; we don't need to say everything |
159 |
p1 is interpolated to p2. This is somewhat similar |
in a 50k view...] |
160 |
to the vob paths from above.) |
|
161 |
|
|
162 |
|
|
163 |
|
-------- |
164 |
|
Analysis |
165 |
|
-------- |
166 |
|
|
167 |
|
|
168 |
|
Role keys |
169 |
|
========= |
170 |
|
|
171 |
|
Role keys are here to stay. This is because indeed they solve |
172 |
|
an important problem-- in a PUI scrollbar, when we've hit |
173 |
|
'PageDown,' how do we animate the box inside the scrollbar |
174 |
|
appropriately without knowing that the two vobs placed |
175 |
|
into the vob scenes before and after interpolation should be |
176 |
|
interpolated to each other? The box has no 'identity' except |
177 |
|
its role in the scrollbar. |
178 |
|
|
179 |
|
Unlike currently used, though, as often as possible role keys |
180 |
|
should be defined publicly in methodless Java interfaces |
181 |
|
(so that they can be shared between all classes that use them). |
182 |
|
In the PUI scrollbar example, we could have:: |
183 |
|
|
184 |
|
interface ScrollbarKeys { |
185 |
|
Object BUTTON_UP_KEY = new Object(), |
186 |
|
BUTTON_DOWN_KEY = new Object(), |
187 |
|
DRAG_BOX_KEY = new Object(); |
188 |
|
} |
189 |
|
|
190 |
|
This would allow two independent scrollbar implementations, |
191 |
|
maybe from two differrent widget toolkits, to be interpolated |
192 |
|
to each other. This is what the vob system is all about: |
193 |
|
Interpolation between views that were not explicitly programmed |
194 |
|
to be interpolatable to each other. |
195 |
|
|
196 |
|
|
197 |
|
What do we think of as a vob? |
198 |
|
============================= |
199 |
|
|
200 |
|
All the time since stage one, a vob has been *a graphical object |
201 |
|
without accessible internal structure*. While in stage one, |
202 |
|
a vob was always associated with an identity, since stage two, |
203 |
|
you can think of it simply as an image transformed by |
204 |
|
a coordinate system; in both cases, though, a vob is a primitive |
205 |
|
you cannot 'look into.' |
206 |
|
|
207 |
|
If a vob (graphical object) has internal structure, this structure |
208 |
|
is not *reified*, that is, it is not accessible through the vob system. |
209 |
|
Consider a vob representing a cell in stage one, above; there may be |
210 |
|
a cell border, textual content (possibly broken over multiple lines), |
211 |
|
and a line cursor. There definitely is internal structure, but it is |
212 |
|
impossible to substitute, say, a different kind of line cursor |
213 |
|
on the vob system level, since it treats the whole cell vob as |
214 |
|
an indivisible entity. |
215 |
|
|
216 |
|
Hierarchical coordinate systems (stage three) attempt to solve |
217 |
|
this problem by modelling only the primitive graphical objects |
218 |
|
as vobs. A cell would be drawn by using a border vob, one or more |
219 |
|
text vobs, and a line vob to show the cursor. |
220 |
|
|
221 |
|
But consider what we'd consider to be a 'vob' or 'visual object' |
222 |
|
as an application programmer. The paradigm is that we place |
223 |
|
'visual objects' on the screen by putting them into coordinate |
224 |
|
systems; how would we interpret this when programming, for example, |
225 |
|
a zzstructural view? -- It seems to me that the earlier stages |
226 |
|
match the expectations better: the 'visual objects' are the cells; |
227 |
|
what's inside them is simply of no concern. |
228 |
|
|
229 |
|
I think it is here that the current vob system errs. By only |
230 |
|
providing for atomic objects as vobs, it forces the |
231 |
|
application programmer into micromanagement. I believe that |
232 |
|
a better definition of vob would be *a graphical object |
233 |
|
with ignorable internal structure*: An object |
234 |
|
which can be safely treated as a unit, ignoring its internals, |
235 |
|
but can also be seen as a collection of things. |
236 |
|
|
237 |
|
I propose to make ``Vob`` an interface with a ``place`` method, |
238 |
|
putting the given vob into a coordinate system. Additionally, |
239 |
|
I propose a ``Renderable`` subclass of ``Vob`` which takes on |
240 |
|
the current meaning of ``Vob``: an indivisible graphical primitive. |
241 |
|
Only ``Renderable`` objects can be placed into a ``VobMap``, |
242 |
|
and this is what a default ``place`` implementation |
243 |
|
in ``Renderable`` does. A more complex ``Vob`` implementation |
244 |
|
could create new coordinate systems inside the coordsys |
245 |
|
given to its ``place`` method, putting other vobs into |
246 |
|
these sub-coordsys. A vob showing a cell could be implemented |
247 |
|
that way. |
248 |
|
|
249 |
|
.. uml:: vob_and_renderable |
250 |
|
|
251 |
|
class Vob "interface" |
252 |
|
methods |
253 |
|
place(into) |
254 |
|
|
255 |
|
class Renderable |
256 |
|
inherit Vob |
257 |
|
|
258 |
|
--- |
259 |
|
vertically(50, foo, Vob, Renderable); |
260 |
|
|
261 |
|
(The naming is a little bit ironic, since in the first stage |
262 |
|
vob system, ``Flob``, the predecessor of ``Vob``, was |
263 |
|
a subclass of ``Renderable``. Yet, it fits the roles really well.) |
264 |
|
|
265 |
|
``Vob`` could become a superinterface of the current ``HBox``, |
266 |
|
which adds methods to request the size and baseline at a given scale. |
267 |
|
Indeed it could be useful to put requests for size information |
268 |
|
into ``Vob``, leaving only baseline requests to ``HBox`` ("``HVob``"?). |
269 |
|
This would bring the interface close to ``CellView``; it may even |
270 |
|
be possible to unify ``Vob`` and ``CellView``. These are details |
271 |
|
out of scope for this PEG, though. |
272 |
|
|
273 |
|
``Vob.place()`` should return the coordinate system given to it; |
274 |
|
this allows writing :: |
275 |
|
|
276 |
|
box = vob.place(vs, vs.boxCS(cs, key, 250, 250, 50, 50)) |
277 |
|
|
278 |
|
-- i.e., making the placement of a vob a one-liner, |
279 |
|
which it should really be (since it should be an atomic action |
280 |
|
in the application programmer's mind), without losing the coordsys |
281 |
|
the vob was placed into (``vs.matcher.getCS(key)`` only works |
282 |
|
for non-repeating views, i.e. views that never use |
283 |
|
the same key twice under any circumstances). |
284 |
|
|