From be49b799a2397bee4cf5cf7c86bf1bfd366f1ade Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Thu, 18 Oct 2007 17:35:06 +0200 Subject: [PATCH] typo --- wiki/renderengine.html | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 2aaac1a79..d09474bec 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -1359,8 +1359,8 @@ From experiences with other middle scale projects, I prefer having the test code {{red{how to create a test stub for this interface...?}}} -
-
Used to actually implement the various kinds of [[Placement]] of ~MObjects. ~LocationPin is the root of a hierarchy of different kinds of placing, constraining and locating a Media Object. Basically, this is an instance of the ''state pattern'': The user sees one Placement object with value semantics, but when the properties of the Placement are changed, actually a ~LocationPin object (or rather a chain of ~LocationPins) is changed within the Placement. Subclasses of ~LocationPin implement different placing/constraining behaviour:
+

+
Used to actually implement the various kinds of [[Placement]] of ~MObjects. ~LocatingPin is the root of a hierarchy of different kinds of placing, constraining and locating a Media Object. Basically, this is an instance of the ''state pattern'': The user sees one Placement object with value semantics, but when the properties of the Placement are changed, actually a ~LocatingPin object (or rather a chain of ~LocatingPins) is changed within the Placement. Subclasses of ~LocatingPin implement different placing/constraining behaviour:
 * {{{FixedLocation}}} places a MObject to a fixed temporal position and track
 * {{{RelativeLocation}}} is used to atach the MObject to some other anchor MObject
 * //additional constraints, placement objectives, range restrictions, pattern rules will follow...//

@@ -2085,16 +2085,16 @@ DAMAGE.
 
 The fact of being placed in the [[Session|SessionOverview]]/[[EDL]]is constitutive for all sorts of [[MObject]]s, without Placement they make no sense. Thus — technically — Placements act as ''smart pointers''. Of course, there are several kinds of Placements and they are templated on the type of MObject they are refering to. Placements can be //aggregated// to increasingly constrain the resulting "location" of the refered ~MObject. See → [[handling of Placements|PlacementHandling]] for more details
-
+
[[Placement]]s are at the very core of all [[editing operations|EditingOperations]], because they act as handles (smart pointers) to access the [[media objects|MObject]] to be manipulated. Moreover, Placements are the actual content of the EDL(s) and Fixture and thus are small objects with //value semantics//. Many editing tasks include finding some Placement in the EDL or directly take a ref to some Placement. By acting on the Placement object, we can in some cases change parameters of the way the media object is placed (e.g. adjust an offset), while by dereferencing the Placement object, we access the "real" media object (e.g. for trimming its length). Placements are ''templated'' on the type of the actual ~MObject they refer to, thus defining the interface/methods usable on this object.
 
-Actually, the way each Placement locates its subject is implemented by one or several small LocationPin objects, where subclasses of LocationPin implement the various differend methods of placing and resolving the final location. Notably, we can give a ~FixedLocation or we can atach to another ~MObject to get a ~RelativeLocation, etc.
+Actually, the way each Placement locates its subject is implemented by one or several small LocatingPin objects, where subclasses of LocatingPin implement the various differend methods of placing and resolving the final location. Notably, we can give a ~FixedLocation or we can atach to another ~MObject to get a ~RelativeLocation, etc.
 
-Placements have //value semantics,// i.e. we don't stress the identity of a placement object (~MObjects on the other hand //do have// a distinguishable identity): initially, you create a Placement parametrized to some specific kind (fixed, relative,...), but later on, you treat the placement polymorphically and don't care about its kind. The sole purpose of the placement's kind is to select some virtual function implementing the desired behaviour. There is no limitation to one single Placement per ~MObject, indeed we have several different Placements of the same MObject (from a users point of view, this behaves like having clones). Besides, we can ''aggregate'' additional [[LocationPin]]a to one Placements, resulting in their properties and constraints being combined to yield the actual position of the referred ~MObject.
+Placements have //value semantics,// i.e. we don't stress the identity of a placement object (~MObjects on the other hand //do have// a distinguishable identity): initially, you create a Placement parametrized to some specific kind (fixed, relative,...), but later on, you treat the placement polymorphically and don't care about its kind. The sole purpose of the placement's kind is to select some virtual function implementing the desired behaviour. There is no limitation to one single Placement per ~MObject, indeed we have several different Placements of the same MObject (from a users point of view, this behaves like having clones). Besides, we can ''aggregate'' additional [[LocatingPin]]a to one Placements, resulting in their properties and constraints being combined to yield the actual position of the referred ~MObject.
 
 !design decisions
-* the actual way of placing is implemented similar to the ''State Pattern'' by small embedded LoctionPin objects.
-* these LocationPin objects form a ''decorator'' like chain
+* the actual way of placing is implemented similar to the ''State Pattern'' by small embedded LocatingPin objects.
+* these LocatingPin objects form a ''decorator'' like chain
 * resolving into an ExplicitPlacement traverses this chain
 * //overconstraining// a placement is not an error, we just stop traversing the chain (ignoring the remaining additional Placements) at the moment the position is completely defined. 
 * we provide subclasses to be able to form collections of e.g. {{{Placement<Effect>}}}, but we don't stress polymorphism here. Instead we stick to value semantics and explicitly ''allow slicing'' (all subclasses have the same size and layout and differ only in their vtable contents). This is justified, because for the polymorphical treating of ~MObjects the visitor mechanism used by the builder and the EDL is sufficiant, and I don't want to add another layer of complexity by making Placement something like {{{boost::variant}}}.