This includes `array`, `base`, `bezcurve`, `block`, `bspline`,
`circle`, `clone`, `dimension`, `draft_annotation`, `draftlink`,
`drawingview`, `ellipse`, `facebinder`, `fillet`, `label`,
`patharray`, `point`, `pointarray`, `polygon`, `rectangle`,
`shape2dview`, `shapestring`, `text`, `wire`, `wwproxy`.
These are added to the `draftobjects` Doxygen group
so that the functions and classes contained in each module
are listed appropriately in the automatically generated
documentation.
These functions were previously in `draftutils.utils`,
and are related to grouping objects and finding objects
inside groups. These include `get_group_names`, `ungroup`,
`get_windows`, `get_group_contents`, `get_movable_children`.
These are imported in the main `Draft.py` module, so compatibility
is retained.
Modules which use these functions are updated; these include
Gui Commands like `Move`, `Rotate`, `Scale`, `AddToGroup`,
as well as objects like `DrawingView` and `Shape2DView`,
and `ViewProviderClone`.
The code inside the `importDXF` module is also updated.
The Arch Workbench uses many of these functions
but it does so from the `Draft` namespace, so these edits
don't change the situation for these commands.
This class is the base of the viewproviders of annotation-type
objects like dimensions (linear, radial, angular), labels,
and texts.
The basic properties of `ViewProviderDraftAnnotation`
are set up by a method `set_properties`, which can be called
in the derived classes.
In the general proxy object `DraftAnnotation` we implement
the `onDocumentRestored` method in order to add the missing
view property `AnnotationStyle` to older objects.
At the moment the user must manually modify `FirstAngle`
and `LastAngle` to obtain a new `Angle`, but since the values
are manually entered the result is not tied to any actual object
in the document.
We introduce a function `measure_two_obj_angles`
to calculate the corresponding parameters from a pair of objects
and their edges.
Currently this function is deactivated because it is intended
for testing purposes only.
This needs to be improved because at the moment it only gives
two possible angles. We should be able to get the four angles
of a two-line intersection. Maybe a new property is required
to indicate the quadrant to choose and display.
Instead of placing the entire code in the `execute` method,
we use three medthods to extract the `Start` and `End` dimension
points from different combinations of edges.
One method to get the dimension from a single object, from the edge,
either linear or circular; one method to get the dimension
from a single object, from two vertices; one method to measure
the distance between two objects, from two different vertices.
There are three classes `DimensionBase`, `LinearDimension`, and
`AngularDimension`, their properties are set only if they don't
already exist.
Provide also better documentation in the tooltips,
and use `setPropertyStatus` to hide and show the intended
properties in the property editor.
The `Support` property is not used at all except as a way to
store an object, so it should probably be removed in the future.
Previously the `make_dimension` and `make_angular_dimension`
functions were in `draftobjects/dimension.py`.
Now they are moved to `draftmake/make_dimension.py`.
The original `makeAngularDimension` function requires angles
in radians which is counterintuitive for most cases. Also
the order is `[big, small]`.
The new function `make_angular_dimension` accepts angles
in degrees, and the order is `[small, big]`. The older
function is retained for compatibility purposes.
Also perform several improvements such as PEP8 cleanup,
writing complete docstrings, type checking the input arguments,
and depreacting the older call.
The `Draft.py` module, Gui Command, unit test, and test script
are updated accordingly.
When `LabelType` is `'Custom'`, the `Target` property
is hidden and `CustomText` is shown.
For other values of `LabelType`, `Target` is shown,
and in turn `CustomText` is hidden.
This avoids showing unused information in the property editor.
We use smaller functions to return a list of strings corresponding
to each basic value of `LabelType`. Then the final `Text` value
can be defined as a simple value, or as the concatenation
of two smaller lists, depending on the value of `LabelType`.
Since we have 8 basic values, we could return up to 8^2
combinations, but at the moment we only return 8 basic
values and 5 simple combinations, which are the ones
that make the most sense.
In the future we could define new properties, say, `LabelType2`
and `LabelType3`, to be able to combine two or three types
of strings in an arbitrary fashion. At the moment, the possible
combinations are hard coded in `LabelType`.
Instead of placing the entire code in the `execute` method,
a `return_info` function is used to return the specific string
that we wish to display depending on the `Target` object,
the `LabelType`, and subelement in `Target`, if any.
We also make the code more readable by using smaller variables,
and avoiding notations with lists of lists (`variable[0][1][6:]`).
There are three general types of properties, target, leader,
and label; so we set the 9 properties using three functions,
and provide better documentation in the tooltips
for each property.
Also perform several improvements such as PEP8 cleanup,
writing complete docstrings, type checking the input arguments,
and deprecating the older call.
Update `Draft.py`, the Gui Command, the unit test, and test script
as well.
The use of `App::PropertyLinkSubList` for `'PathSubelements'`
is a mistake because we could use a single `App::PropertyLinkSub`
to handle both `'PathObject'` and `'PathSubelements'` properties.
This commit doesn't change any code, it just adds comments
explaining the situation so that it is not forgotten,
and we remember to address it in the future.
Ideally we should migrate the objects, but we may also decide
to break compatibility with older `PathArrays` if both properties
can't be migrated easily.
The `Part::Vertex` object has both `Placement`, and `X`, `Y`, `Z`
properties. The net displacement is the sum of both of these two
properties.
Previously, the `PointArray` would only use the `Placement`
which would produce a seemingly erroneous result
because `X`, `Y`, and `Z` would be ignored.
Also perform several improvements such as PEP8 cleanup,
write complete docstring, type checking of the input arguments,
accepting a full placement to modify the position,
and deprecating the older call.
Update the Gui Command as well.
`PathObj` becomes `PathObject`, `Xlate` becomes `ExtraTranslation`,
and `PathSubs` becomes `PathSubelements`.
Update `make_path_array` function and the Gui Command.
Certain properties do not need to be shown in the property editor
when a particular `AlignMode` is chosen. This keeps the number
of properties displayed organized and easy to manage.
Return early from the `execute` method if no base or path exist.
Add method `get_wires` which internally uses `get_wire_from_subelements`
(renamed method), to get the edges from the path object,
and its subelements, if any. If no wires are found
return early from `execute`.
The final rotation applied to the copies will be the base rotation
of the base object's shape. The only exception is when the
`AlignMode` is `'Tangent'`; in this case, it performs
a pre-rotation with the `TangentVector`.
Test the inputs to the `make_path_array` function
and return `None` if there is a problem.
Now the make function accepts as input a `"String"` which must be
the `Label` of an object in the document, so it is easier to create
arrays quickly from the Python console.
Add the new parameters to the make function, `align_mode`,
`tan_vector`, `force_vertical`, and `vertical_vector`.
These properties were added to the proxy object in 0db11da9cf.
Add message deprecating the older call `makePathArray`.
Adjust the GuiCommand accordingly. Now it uses the commit
mechanism of the parent `Modifier` class so that the executed
functions are recorded in the Python console.
Clean up the `PathArray` class as well.
This way they can be tested individually in the Python console
without needing the `Array` class at all. In the future these
methods could be moved to `DraftGeomUtils` or to `draftfunctions`.
Since the `Array` class handles three different types, they
have different sets of properties. We add them to specific functions
so that they are clearly identified.
This class was created by realthunder during the `LinkMerge`,
in 8cd9339b8c, to demonstrate how to use the `App::Link`
objects to create Link aware arrays.
It is used by `draftobject.array` (ortho, polar, circular)
and `draftobject.patharray` to create respective Link arrays.
This class is a bit mysterious. We need more documentation
on how the properties are being set, and how the code interacts
with the arrays that use it.
The displacement is added to the position already defined by
the point, in order to impart an additional shift in the copy.
The rotation is also added to the original shape's rotation
by multiplying the quaternions.
Implement `onDocumentRestore` to add the new property
to older objects.
Test the inputs to the `make_point_array` function
and return `None` if there is a problem.
Now the make function accepts as input a `"String"` which must be
the `Label` of an object in the document, so it is easier to create
arrays quickly from the Python console.
Add a message deprecating the older call `makePointArray`.
Adjust the GuiCommand accordingly. Now it uses the commit
mechanism of the parent `Modifier` class so that the executed
functions are recorded in the Python console.
Clean up the `PointArray` class as well.
Older PathLinkArray objects had a `useLink` attribute
which was migrated to `use_link`. A recent commit, 0db11da9cf,
made some improvements to the PathArray
object, but broke the migration of the property.
This fixes the migration, so that now all objects should
open correctly.
Previously they were in `draftobjects`, but since they
don't define new objects, just create objects,
they are moved to `draftmake`.
Also ajust the `CMakeLists.txt` and the corresponding Gui Commands
which use these make functions.
These functions internally use the `Draft.makeArray` function.
We will put comments as reminders so that when this function
is moved to its own module, we can update the derived functions.
