Most of App::Origin is moved into this sub class of App::Origin.
Add App::Point. Change graphics of the planes/axis.
Remove scale-by-content behavior and make it fixed size on screen.
Fixes#16249.
The input did receive the focus, but the existing value was not selected.
The circle, arc, trim and offset tools had a related issue. The whole radius/distance value, including the unit string, was selected, instead of just the numerical portion.
Fixes#16550.
Fixes#16552.
* Layer blocks receive a name with the "LayerBlock_" prefix.
* They are put in a layer if the "Use layer" import option is checked.
* If Draft or Sketch objects are created a Part_Compound instead of a Draft_Block is created. This was done because a Draft_Block does not claim its children. I am not sure about this change. Maybe the behavior of the Draft_Block should be changed instead.
@yorikvanhavre: do you know why a Draft_Block does not claim its children?
It seems that Base has very handy helpers for converting between various
types. This simplifies code of ViewProviderAssembly::get/setDraggerPlacement a
lot.
Add dynamic attributes to report the physical attributes of a part that
are automatically recalculaated when the shape or material changes.
These values are accessible from the part data display and as attributes
within Python
If `get_diffuse_color` returned a list with a single color, the list was wrongly multiplied. Regression introduced in V0.21, but in that version the error was masked by how Core handled the diffuse color.
Fixes#17052.
* [Draft gui_stretch] Improve Stretch Rectangle Behaviour
Feature Improvement discussed at FreeCAD Forum :
- https://forum.freecad.org/viewtopic.php?t=92124#p792118 (Draft_Stretching the whole rectangle creates a new wire)
Currently, 3 cases in general, proposed PR improve Case 3 below :
1. The original object is a Rectangle, if after stretching it is no longer a rectangle, it makes a copy turning it into a Wire which reflect the result of stretching.
- Current behanviour is good for user, no change.
2. If after stretching it is still a rectangle, the code just resize the original.
- Current behanviour is good for user, no change.
3. Now, if the user 'stretch' the whole rectangle, the code creates a copy as DWire in the 'stretched location'.
** - Users find this not intuitive, better just move the whole rectangle.
* For the human figure attached to the Draft grid a hard-coded point list is used (instead deriving the points from human figure.brep). This is more efficient and avoids a dependency on the BIM WB.
* The default for the human figure preference of the grid was changed to false. And the tooltip adjusted.
* BIM: Fix calculation of fence sections
The length and placement of fence sections was only correct if they were cut to size.
* Fix required another change.
Fixes#16832.
In V1.0 the two Draft status bar widgets appear as checkboxes without label in the toolbar area context menu. They should not be listed in that menu, as was the case in V0.21. Their visibility is controlled via preferences.
Additionally, in case the Draft WB is only preloaded, the widgets would display in another workbench. This is prevented by using a delay.
To harmonize the various CAM operations, the helical drill shall also be
configured using the cut mode (Climb/Conventional) just like Pocket or
FaceMill.
This means, the path direction (CW/CCW) is now a hidden read-only output
property, calculated from the side (Inside/OutSide) and the here newly
introduced cut mode.
The spindle direction is not yet taken into account and is always assumed
to be "Forward".
The GUI strings are kept compatible with what RP#14364 introduced becasue
of the v1.0 release string freeze. They need revision once back on the
main branch.
This reverts commit 7e62d07538 and adapts
to the in between commits where necessary.
- CAM: apply precommit 7274dac185
- CAM: rename "Tests" to "CAMTests" 2ff4914fd8
Motivations for the revert:
- Instead of actually implementing #14364 only a search and replace in
the enums values has been performed. But this does not mean the
feature is there, becasue "climb"/"conventional" milling depends not
only on the path's direction, but also on the spindle direction and
whether the milled feature is "inside" or "outside".
- In half of the cases of every changed operation or dressup, depending
on whether we mill "inside" or "outside", we now get the wrong results.
- In the (rarer) case of a reversed spindle direction, the "other half"
is wrong.
- Files created with previous versions of FreeCAD cannot be recomputed
any longer because there were no precautions on document restore.
- In files created with previous versions of FreeCAD one cannot change
the broken operation as the choices are now invalid.
- The original search/replace was incomplete.
- Only property values have been changed, the property names are still
inconsistent ("Direction" vs "Cutting Mode").
- The original search/replace also changed internal APIs where the
"climb"/"conventional" wording is not applicable as there is no
notation of "inside"/"outside" or "forward"/"reverse". If only the
path's direction is concerned, "CW"/"CCW" fits better.
Since the fixture in use has holes smaller than the default tool dimeter,
executing a helix operation with default parameters (i.e. all holes)
used to fail with an exception. Some tests work around this by actively
chaning the tool diameter, and this fix is now moved into the global
setup where the respective fixture is loaded.
The reason why the tests got disabled in the first place is unclear.
This demonstrates a regression introduced with PR #14364, where documents
containing helix operations cannot be recomputed any more (see #15643).
This is in preparation for a fix and to ensure we don't break it again.
The fixture has been created with the official mac build of FreeCAD-0.21.1
In ../src/Mod/Part/App/Geom2d/ sixteen out of seventeen XML
files needed repair as per the GitHub issue. Tabbing in those
sixteen files set to 4-spaces no-tab-chars. Other minor
changes as needed.
