This class is also derived on `ViewProviderDimensionBase`.
It is used to measure the angle between two straight lines.
Various improvements in style, PEP8, spacing, docstrings.
In particular use more readable variable names.
The `updateData` method is modified to return immediately
if the `arc` attribute does not exist. This is better
to reduce the level of indentation of the code.
This class handles linear dimensions of edges, or radial
dimensions of arcs and circles.
Various improvements in style, PEP8, spacing, docstrings.
In particular use more readable variable names.
The modules `Part` and `DraftGeomUtils` have been delayed
in import.
The `updataData` method is modified to return immediately
if the Proxy property modified is different from `Start`,
`End`, `Dimline` or `Direction`.
Use methods to set up the properties. As the dimension object has
16 properties, these properties are assigned using three methods
corresponding to text, units, and graphics properties.
The functions `getDefaultUnit`, `makeFormatSpec`, `displayExternal`
are used to get the default unit schema for lengths and angles,
and display a string with a particular format.
They aren't used in `DraftGui.py`, but are used by the
viewprovider of the Dimension objects. Therefore, they are moved
into a separate module, so that they can be imported without
using the entire `DraftGui` module.
Various improvements in style, PEP8, spacing, docstrings.
Improve the methods to update the text, the arrow, and the frame
of the label.
Options to handle `Justification` and `LineSpacing` are added.
These can be handled just like with the `ViewProviderText` object,
as the internal text node is the same, a `SoAsciiText`.
Nevertheless, currently the leader line and the frame that are
drawn for the label don't consider the correction in position
for the `Justification` or `Linespacing` so the graphics
may be overlapped in certain situations.
Various improvements in style, PEP8, spacing, docstrings.
The list of strings is set to empty before being assigned again.
This solves a problem of the text not being updated correctly.
In the past some `try-except` blocks were there to catch and
ignore certain exceptions that apparently were caused by a
race condition, where certain properties are not assigned
to the object before they are used. These errors
don't seem to occur in v0.19, so we removed the exception
handling. We leave comments mentioning the issue
in case it re-appears.
The `DisplayMode` is swapped, so now `'2D text'` means that the
text always faces the camera, and `'3D text'` means that the
text can be positioned in different orientations in the 3D space.
This is consistent with the `Draft Label` behavior.
A function `draftutils.gui_utils.migrate_text_display_mode`
is provided to help migrate older objects of type `Text`
or `DraftText` to the new display mode.
The classes `ViewProviderDimensionBase`, `ViewProviderLinearDimension`,
`ViewProviderAngularDimension`, `ViewProviderText`, and
`ViewProviderLabel` use `super()` to call the `onChanged` method
of the parent class `ViewProviderDraftAnnotation`.
In this way the `AnnotationStyle` property correctly modifies
the properties of every annotation object.
Add view properties of dimensions, labels, and text objects
through methods, calling the parent classes, and `ViewProviderDraftAnnotation`
when needed.
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.
These style properties are used by `ViewProviderDraftAnnotation`
and by the Gui Command `Draft_AnnotationStyleEditor`.
Therefore, they are moved from `draftguitools.gui_annotationstyleeditor`
module to the `draftutils.utils` module, so that they
are in a central location where they won't cause circular
dependencies.
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.
A single `make_dimension` handles three types of dimensions,
(1) simple linear, (2) linear linked to an object, and (3) linked
to a circular edge.
So, we provide a new function, `make_radial_dimension_obj`,
to handle the third case. In this way we can check the input
parameters much better.
We adjust the `Draft_Dimension` Gui Command accordingly.
A single `make_dimension` handles three types of dimensions,
(1) simple linear, (2) linear linked to an object, and (3) linked
to a circular edge.
So, we provide two new functions, `make_linear_dimension`
and `make_linear_dimension_obj`, to handle the first two cases.
In this way we can check the input parameters much better.
We adjust the `Draft_Dimension` Gui Command accordingly.
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.
This commit just syncs with the pattern of TechDraw:
- add further patterns
- save all patterns as plain SVG (strictly following thee SVG specifications) using Inkscape 1.0
Before, the `make_label` function had a `target` parameter
that had to be a `LinkSub`, `[Part::Feature, "Edge1"]`.
However, it is easier to pass the individual components
separately using two parameters, `target_object` and `subelements`,
which can then be assembled into `[target_object, subelements]`.
The second element is optional, so it can be set to `None`,
and then the second element will be converted to an empty list,
`[target_object, []]`, as required by the Label's underlying `Target`
property.
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.
This function, `draftutils.gui_utils.format_object`,
takes the value defined in the `DrafToolBar`, and uses it
to specify the `FontSize` for `Text` objects.
Now it specifies the `TextSize` for `Label` elements as well.
When the value of the `Text` is changed, in the Coin node
only the first element in the list of strings is updated,
the other elements remain the same, resulting in an incorrect
label.
So we empty the value of the Coin string with `setValue("")`,
and then we can assign the new string list, producing the correct
expected result.
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.
- Python3 does not allow to write strings to a file opened as "wb"; it
expects bytes instead. Since ASCII DXF files are written using strings,
the file should be opened as "w". Should be ok for python2 as well.
- See also issue 003862, https://tracker.freecadweb.org/view.php?id=3862
Import the modules inside `DraftGeomUtils.py` in increasing order
of complexity. For example, the basic module is `general`,
and `geometry`, `edges`, `faces`, `arcs`, and `cuboids`
after it.
On the other hand the `circles_apollonius` module requires
various of those dependencies, so we import it at the end.
We don't import any of the `circles_incomplete` functions
because these are incomplete and we need to implement
the dependency functions first.
