* [PD] get rid of a CI compiler warning
The CI compiler outputs this warning:
FeaturePad.cpp:101:20: warning: variable 'obj' set but not used [-Wunused-but-set-variable]
Co-authored-by: 0penBrain <48731257+0penBrain@users.noreply.github.com>
It is important to not include the original in the pattern because the original might not be at the tip of the feature tree. Including the original
will interfere with changes that occur further down in the feature tree
This fixes the bug identified in
https://forum.freecadweb.org/viewtopic.php?f=3&t=64900
By reusing the property docs as tooltip we avoid maintaining the same
information in two places. The propery descriptions have been made
translatable, too, to ensure a fully translatable UI.
The ground work for this was layed by the work on Issue 0002524, long
time ago: https://tracker.freecadweb.org/view.php?id=0002524
- The thread must not be deeper than the hole.
(One could see that if one used a thread depth dimension and set
it to the same value than the hole depth, the thread was too deep.)
- actually use specified thread depth, fixes issue reported here: https://github.com/FreeCAD/FreeCAD/pull/4274#issuecomment-997787744
- fixes 2 UI enabling issues
- the thread depth cannot be longer than the hole depth
- the hole cannot be deeper than the through-all depth
[PD]: Fix helix property visibility/writeability
* Hide irrelevant and internal helix properties
- The `HasBeenEdited` property is only used internally to check whether to
fill certain other parameters with initial values. So there is no need
show it in the property grid at all.
- The `Outside` property is only used in the subtractive helix and thus
hidden for the additive helix.
* Make derived helix properties read-only
Depending on the input mode, some properties are primary input, others
are derived. Prior to this change, also the derived properties have been
writable but their values are ignored and overwritten on the next
recompute. Now, when changing the input mode, only the primary input
props are writable.
* Reorder some helix properties
This change puts the reference axis and input mode at the top to become
more prominent. Only "Base" and "Axis" are higher in the list for
consistency with the other axis-based features.
Depending on the input mode, either `Growth` or `Angle` is used to create
a conical or flat spiral. The respective other can easily be calculated
to give consistent view. This is already done for the other properties,
e.g. `Height` is calculated from `Pitch` and `Turns`.
With this patch, the same is done for `Angle` and `Growth`.
Introduce an enum to verify the axis depending on the used context.
* For helix no restriction is needed
* For Pad/Pocket the axis must not be parallel with the sketch plane
* For Revolve/Groove the axis must not be perpendicular with the sketch plane
Helices that become smaller with every turn are geometrically perfectly valid. Therefore we cannot forbid this.
(For example when creating a helix from a face you often cannot move it so that you can apply a positive growth.)
Previously, only the vertical and horizontal axis of the profile was
selectable in the task panel of the additive/subtractive helix. Now the
profile's normal axis can be selected, too. This now allows to create
helical extrusions or "twisted pockets".
The order of the GUI entries was chosen to be in line with the order of
axis selection of the multi-transform parameters.
The actual feature's implementation needed adaption for this special case
as in some places a unit vector (`gp_Dir`) was derived from the cross-
product of axis and profile normal -- a null-vector when the axis *is*
the normal. This caused the gp_Dir's ctor to throw.
Used when finding subelements of a feature. Many of the comparisons used to also
check for string lengths, but as far as I can tell they are not strictly
necessary (see https://www.cplusplus.com/reference/string/string/substr/) and
just `substr` can be used without them. However, `compare` explicitly is for
comparing, and does not make a new object that `substr` does.
Similar to PR #5170 for loft. This commit squashes the following commits.
[PD] Refactor `Pipe::execute` and support point sections
[PD] Allow point profile in selection-based pipe workflow
[PD] Only add sketch subs if it is vertex
[PD] Make both end faces of pipe regardless of point sections
Earlier we were checking if these faces correspond to point sections, but
apparently the end faces are independent of the order in which the sections are
added, so the "front" may be the face closest to the last added section, rather
than the "profile". Creating null faces and adding them for sewing together into
a solid does not appear to have side-effects so far.
- let FeatureExtrude set the right direction
- use the UI as once intended: custom vector values are always taken as they are, so reversing a custom direction will not lead to a negation of the custom vector in the UI. The logic is: "take the vector as it is, and when Reversed is on, negate it additionally"
This is a combination of 4 commits. Original commit messages follow.
[PD] Initial support for point sections in loft
This commit allows the last section in a loft to be a single vertex of a solid.
Currently single vertices of sketches or datum points are NOT supported.
[PD] Allow loft "profiles" to be points
Most reliably done in dialog-based workflow.
[PD] Allow loft last section to be sketch point
[PD] Refactor `Loft::execute`
Makes it easier to support adding a single-vertex sketch in profile or sections
field when selecting the sketch in tree (i.e. without selecting subelements).
[PD] Refactoring after PR #5176 is merged
This PR adds the functionality of pads to pad along either a custom direction or along an edge to pockets.
So with this PR Pad and Pocket are on the same level of functionality.
With these changes, one face per solid can be added as either the first
"profile" or subsequent sections in loft and pipe.
This commit depends on `App::PropertyXLinkSubList` preserving the order in which
sections are added.
A minor change this also adds is that when a solid's face is selected that face
is mentioned in the fields instead of the solid (eg `Box:Face1` instead of
`Box`).
