summaryrefslogtreecommitdiffstats
path: root/kig/DESIGN
diff options
context:
space:
mode:
authortpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2011-06-11 04:44:41 +0000
committertpearson <tpearson@283d02a7-25f6-0310-bc7c-ecb5cbfe19da>2011-06-11 04:44:41 +0000
commita374efce3a207b39514be3c52264091400ce297e (patch)
tree77bdf654b55826d4f59b53a5621310206bcaead1 /kig/DESIGN
parentf81a494f3957d5cf38c787973415597941934727 (diff)
downloadtdeedu-a374efce3a207b39514be3c52264091400ce297e.tar.gz
tdeedu-a374efce3a207b39514be3c52264091400ce297e.zip
TQt4 port kdeedu
This enables compilation under both Qt3 and Qt4 git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/kdeedu@1236073 283d02a7-25f6-0310-bc7c-ecb5cbfe19da
Diffstat (limited to 'kig/DESIGN')
-rw-r--r--kig/DESIGN32
1 files changed, 16 insertions, 16 deletions
diff --git a/kig/DESIGN b/kig/DESIGN
index fd887779..6d4a8c37 100644
--- a/kig/DESIGN
+++ b/kig/DESIGN
@@ -19,7 +19,7 @@ An ObjectImp represents the current state of an object in Kig. It
keeps information about what type of object it is ( e.g. a line, a
point, a circle etc. ), and its exact data ( e.g. the center and
radius of the circle ). It is *not* in any way aware of how the
-object was calculated from its parents (e.g. is this a line that is
+object was calculated from its tqparents (e.g. is this a line that is
constructed as the parallel of another line, or as the line going
through two given points ? ) or how it is drawn on the window (
e.g. the thickness of the line, its color etc. ).
@@ -50,21 +50,21 @@ calculating an ObjectImp from other ObjectImp's. It is also a node in
the dependency graph of a certain document. E.g. a LineImp can be
calculated from the two PointImp's it has to go through; every time
either of them moves, this calculation is redone. In this case, there
-would be an ObjectCalcer that keeps a reference to its two parents (
+would be an ObjectCalcer that keeps a reference to its two tqparents (
the ObjectCalcer's representing the points ), and that will calculate
its ObjectImp value every time it is asked to do so ( i.e. every time
-one of its parents moves.. ).
+one of its tqparents moves.. ).
Because of the complex relations that ObjectCalcer's hold to other
ObjectCalcer's and to other classes, they have been made
reference-counted. This means that they keep a count internally of
how much times a pointer to them is held. If this count reaches 0,
this means that nobody needs them anymore, and they delete themselves.
-E.g. an ObjectCalcer always keeps a reference to its parents, to
+E.g. an ObjectCalcer always keeps a reference to its tqparents, to
ensure that those aren't deleted before it is deleted.
In the inheritance graph of a document, the lowermost objects keep
-references to their parents and those keep reference to their parents,
+references to their tqparents and those keep reference to their tqparents,
so that all of the top of the graph is kept alive. Of course, someone
needs to keep a reference to the bottommost objects in the graph,
because otherwise, the entire graph would be deleted. As we will see
@@ -76,7 +76,7 @@ At the end of the program, this reference is released, and all the
objects are deleted.
A special case of an ObjectCalcer is the ObjectConstCalcer. This is
-an ObjectCalcer that has no parents, and only holds some data. The
+an ObjectCalcer that has no tqparents, and only holds some data. The
data is held as an ObjectImp of some type, and it will remain
constant, and no calculation needs to be done to get it, it is just
returned every time it is needed.
@@ -158,10 +158,10 @@ Most of this is handled by the TextType class.
2.1.2 TextType
-The TextType class is an implementation of an ObjectType. It contains
-code specifying how to calculate a TextImp from its parents, and for
+The TextType class is an implementation of an ObjectType. It tqcontains
+code specifying how to calculate a TextImp from its tqparents, and for
how it behaves on user input. A text object has at least three
-parents, and can handle any number of optional arguments. The three
+tqparents, and can handle any number of optional arguments. The three
mandatory arguments are an int, which is set to 1 or 0 depending on
whether the label needs a surrounding box, a PointImp, containing the
location of the text label, and a string containing the text of the
@@ -170,7 +170,7 @@ additional argument is used to replace the lowest-numbered of those
tokens, with its string representation. The function
ObjectImp::fillInNextEscape is used for this.
-For example, if a TextType has the following parents:
+For example, if a TextType has the following tqparents:
a IntImp with value 0
a PointImp with value (0,0)
a String with value "This segment is %1 units long."
@@ -185,7 +185,7 @@ All this gives labels in Kig a lot of flexibility.
2.2 Locuses
Locuses are a mathematical concept that has been modelled in Kig.
-Loosely defined, a locus is the mathematical shape defined by the set
+Loosely defined, a locus is the mathematical tqshape defined by the set
of points that a certain point moves through while another point is
moved over its constraints. This can be used to define mathematical
objects like conics, and various other things. It has been modelled
@@ -197,7 +197,7 @@ proud of this design.
In the implementation of this, we use the concept of constrained
points. This is a point that is attached to a certain curve. It is
implemented in Kig by the ConstrainedPointType, which takes a CurveImp
-and a DoubleImp as parents and calculates a Point from these by using
+and a DoubleImp as tqparents and calculates a Point from these by using
the CurveImp::getPoint function.
2.2.2 The Implementation
@@ -213,7 +213,7 @@ smallest part of the hierarchy that contains all paths from the first
point to the second point. We then determine all objects that are not
*on* one of those paths ( meaning that they are not calculated from
the first point, or another object that is on one of those paths ),
-but that are parents of one or more objects that are on those paths.
+but that are tqparents of one or more objects that are on those paths.
I call this set of objects the "side of the path" sometimes in the
code. The function that finds them is called sideOfTreePath.
@@ -221,7 +221,7 @@ Next, an ObjectHierarchy object is constructed, which stores the way
to calculate the second point from the first point and the objects
from the previous paragraph.
-An object is then constructed that has as parent the curve parent that
+An object is then constructed that has as tqparent the curve tqparent that
the first point is constrained to, the HierarchyImp containing the
ObjectHierarchy from the previous paragraph, and all the objects from
the "side of the tree". This new object is an ObjectTypeCalcer with
@@ -258,9 +258,9 @@ the constrained point. This is wrong because when the constrained
point moves within the limits of the curve constraining it, the locus
does by definition not change. Also, if the constrained point is
redefined so that it is no longer constrained to any curve, this is a
-major problem, because it would invalidate the locus. Another point
+major problem, because it would tqinvalidate the locus. Another point
is that in practice, the locus depends on more objects than its
-parents alone. This is not a good thing, because it makes it
+tqparents alone. This is not a good thing, because it makes it
impossible to optimise drawing of the objects, using the information
about which objects depend on which others, because this information
is invalid.