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.
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 ff323ebdb5.
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 de66e563e0, 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.
