/[gzz]/gzz/doc/pegboard/vob_considerations--benja/peg.rst
ViewVC logotype

Diff of /gzz/doc/pegboard/vob_considerations--benja/peg.rst

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

revision 1.2 by benja, Fri Dec 6 19:54:19 2002 UTC revision 1.3 by benja, Fri Dec 20 00:45:22 2002 UTC
# Line 24  it tries to formalize things you already Line 24  it tries to formalize things you already
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    
# Line 76  a *role key*. The usual pattern is that Line 82  a *role key*. The usual pattern is that
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    
# Line 84  to the role key phenomenon). Line 90  to the role key phenomenon).
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
# Line 144  representing cells into the vob scene. B Line 154  representing cells into the vob scene. B
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    

Legend:
Removed from v.1.2  
changed lines
  Added in v.1.3

savannah-hackers-public@gnu.org
ViewVC Help
Powered by ViewVC 1.1.26