diff --git a/documentation/src/api_architecture.rst b/documentation/src/api_architecture.rst index eb957af..896beae 100644 --- a/documentation/src/api_architecture.rst +++ b/documentation/src/api_architecture.rst @@ -19,8 +19,8 @@ form. The user interfaces are located in `scripts/`. Currently there is Generators .......... -A (box) generator is an subclass of boxes.Boxes. It generates one -drawing. The subclasses over load .__init__() to set their parameters +A (box) generator is a subclass of boxes.Boxes. It generates one +drawing. The subclasses overload .__init__() to set their parameters and implement .render() that does the actual drawing. Generators are found in ``boxes/generators/``. They are included into @@ -33,18 +33,19 @@ Parts ..... Parts are a single call that draws something according to a set of parameters. -There is a number of standard parts. Their typical params are +There are a number of standard parts. Their typical params are explained in the API docs. -Only real requirement for a part it supporting the move parameter for -placement. +The only real requirement for a part is that it must support the move +parameter for placement. Part Callbacks ++++++++++++++ Most parts support callbacks - either one in the middle for round parts or one for each edge. They allow placing holes or other features -on the part. +on the part, indepenent of edge type. Without using callbacks, you +will not have consistent placement of internal features. Navigation and Turtle Graphics .............................. diff --git a/documentation/src/api_arguments.rst b/documentation/src/api_arguments.rst index 27bb2ca..8f35caf 100644 --- a/documentation/src/api_arguments.rst +++ b/documentation/src/api_arguments.rst @@ -71,6 +71,6 @@ Accessing the Arguments For convenience content of the arguments are written to attributes of the Boxes instance before ``.render()`` is called. This is done by ``Boxes.parseArgs``. But most people won't need to care as this is -handled by the frame work. Be careful to **not overwrite important +handled by the framework. Be careful to **not overwrite important methods or attributes by using conflicting argument names**. diff --git a/documentation/src/api_burn.rst b/documentation/src/api_burn.rst index 5ccb1ba..7b68fe8 100644 --- a/documentation/src/api_burn.rst +++ b/documentation/src/api_burn.rst @@ -34,17 +34,18 @@ cutting this deemed acceptable for a long time: Programmer's perspective ------------------------ -For this to work it is important that outside is drawn in a counter -clock wise direction while holes are drawn in a clock wise direction. +For this to work it is important that outside is drawn in a +counterclockwise direction while holes are drawn in a +clockwise direction. :py:meth:`boxes.Boxes.corner` adjusts the radius automatically according to **.burn**. This propagates to higher level functions. Parts shipped with Boxes.py do take the -burn out-set into account and execute callbacks at the correct position. +burn outset into account and execute callbacks at the correct position. In case developers move to a feature inside of a part or executing callbacks while implementing a part they need to be aware of the burn -correction. :py:meth:`boxes.Boxes.cc` does correct for the out-set if +correction. :py:meth:`boxes.Boxes.cc` does correct for the outset if called without an **y** parameter. But if a value is given one has to add **self.burn** to compensate. Note that the **x** value typically does not have to be corrected as the callbacks are executed from right @@ -52,7 +53,7 @@ underneath the part. A similar approach is necessary when moving to a feature drawn inside the part without the use of callbacks. Here you typically have to -correct for the out-set at the outside of the part and again for in-set +correct for the outset at the outside of the part and again for inset of the hole one is about to cut. This can be done in **x** or **y** direction depending on whether the cut is started vertical or horizontally. diff --git a/documentation/src/api_edges.rst b/documentation/src/api_edges.rst index e3b13f3..93e3d3b 100644 --- a/documentation/src/api_edges.rst +++ b/documentation/src/api_edges.rst @@ -7,11 +7,11 @@ of Boxes.py. This means they start at the current position and current direction and move the current position to the end of the edge. Edge instances have a Settings object associated with them that keeps -the details about how the edge should look like. Edges that are +the details about what the edge should look like. Edges that are supposed to work together share the same Settings object to ensure they fit together - assuming they have the same length. Most edges are -symmetrical to unsure they fit together even when drawn from different -directions. Although there are a few exception - mainly edges that +symmetrical to ensure they fit together even when drawn from different +directions. Although there are a few exceptions - mainly edges that provide special features like hinges. As edges started out as methods of the main Boxes class they still are @@ -19,13 +19,13 @@ callables. It turned out that the edges need to provide a bit more information to allow the surrounding code to handle them properly. When drawing an Edge there is a virtual straight line that is the border the shape of the part (e.g. an rectangle). But the -actual Edge has often to be drawn elsewhere. Best example if probably +actual Edge often has to be drawn elsewhere. The best example is probably the ``F`` Edge that matches the normal finger joints. It has to start one material thickness outside of the virtual border of the part so the cutouts for the opposing fingers just touch the border. The Edge -classes have a number of methods to deal with these kind of offsets. +classes have a number of methods to deal with these kinds of offsets. -A set of instances are kept the ``.edges`` attribute of the +A set of instances are kept in the ``.edges`` attribute of the ``Boxes`` class. It is a dict with strings of length one as keys: * aAbB : reserved to be used in generators @@ -140,7 +140,7 @@ Bed Bolts .. autoclass:: boxes.edges.Bolts -Dove Tail Joints +Dovetail Joints ---------------- Dovetails joints can only be used to join two pieces flatly. This limits their use to closing some round form created with flex areas or @@ -150,7 +150,7 @@ much stronger than simple finger joints and can also bare pulling forces. .. autoclass:: boxes.edges.DoveTailJoint .. autoclass:: boxes.edges.DoveTailJointCounterPart -Dove Tail Settings +Dovetail Settings .................. .. autoclass:: boxes.edges.DoveTailSettings diff --git a/documentation/src/api_examples.rst b/documentation/src/api_examples.rst index ffb1d4f..2e69e47 100644 --- a/documentation/src/api_examples.rst +++ b/documentation/src/api_examples.rst @@ -40,8 +40,8 @@ DisplayShelf .. autoclass:: boxes.generators.displayshelf.DisplayShelf The DisplayShelf is completely made out of rectangularWalls(). It uses -a callback to place all the fingerHolesAt() right places on the sides. -While the use of the Boxes.py API is pretty straight forward the +a callback to place all the fingerHolesAt() at the right places on the sides. +While the use of the Boxes.py API is pretty straightforward the calculations needed are a bit more tricky. You can use the ``debug`` default param to check if you got things right when attempting something like this yourself. diff --git a/documentation/src/api_navigation.rst b/documentation/src/api_navigation.rst index 5994173..98265de 100644 --- a/documentation/src/api_navigation.rst +++ b/documentation/src/api_navigation.rst @@ -8,11 +8,11 @@ last line. Other drawing commands restore the current position after they are finished. Moving the origin like this allows ignoring the absolute coordinates -and do all movement and drawing to be relative to the current -position. The current positions does not only consist of a point on +and for all movement and drawing to be relative to the current +position. The current position not only consists of a point on the drawing canvas but also a direction. -To move the origin to a different location there are these to methods: +To move the origin to a different location there are these two methods: .. automethod:: boxes.Boxes.moveTo .. automethod:: boxes.Boxes.moveArc diff --git a/documentation/src/api_parts.rst b/documentation/src/api_parts.rst index 5d13215..1e46f29 100644 --- a/documentation/src/api_parts.rst +++ b/documentation/src/api_parts.rst @@ -4,7 +4,7 @@ Parts -There are a few parameter shared by many of those parts: +There are a few parameters shared by many of the parts: The callback parameter ...................... @@ -78,9 +78,9 @@ denominate single edge (types) only. PartsMatrix ........... -To place many of the same part partMatrix can used: +To place a grid of identical parts, partMatrix can used: .. automethod:: boxes.Boxes.partsMatrix -It creates one big block of parts. The move param treat this block like on big +It creates one big block of parts. The move param treats this block like one big part.