Found via `codespell -q 3 -L aci,ake,aline,alle,alledges,alocation,als,ang,anid,apoints,ba,beginn,behaviour,bloaded,bottome,byteorder,calculater,cancelled,cancelling,cas,cascade,centimetre,childrens,childs,colour,colours,commen,connexion,currenty,dof,doubleclick,dum,eiter,elemente,ende,feld,finde,findf,freez,hist,iff,indicies,initialisation,initialise,initialised,initialises,initialisiert,inout,ist,kilometre,lod,mantatory,methode,metres,millimetre,modell,nd,noe,normale,normaly,nto,numer,oce,oder,ontop,orgin,orginx,orginy,ot,pard,parm,parms,pres,programm,que,rady,recurrance,rougly,seperator,serie,sinc,strack,substraction,te,thist,thru,tread,uint,unter,vertexes,wallthickness,whitespaces -S ./.git,*.po,*.ts,./ChangeLog.txt,./src/3rdParty,./src/Mod/Assembly/App/opendcm,./src/CXX,./src/zipios++,./src/Base/swig*,./src/Mod/Robot/App/kdl_cp,./src/Mod/Import/App/SCL,./src/WindowsInstaller,./src/Doc/FreeCAD.uml,./build/doc/SourceDocu`
* PartDesign: Improve orientation behavior for conical helices
As identified in the forum
https://forum.freecadweb.org/viewtopic.php?f=3&t=65136
The Freenet orientation mode does not give expected results for helices with cone angle.
By using an auxiliary helix that is axially offset it is guaranteed that the orientation frame
is always consistent with a cylindrical coordinate system.
Results will be the same as before when cone angle is 0.
* [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"