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.
=====================================================================
fixes#4241
Problem:
PartDesignGui::ViewProvider is responsible for closing the tasks for most of PD features when exiting edit mode
(i.e. unsetEdit()).
For primitives, PartDesignGui::ViewProviderPrimitive is responsible, and neither does it or relies on its parent
VP to do it when calling unsetEdit().
Solution:
Make PartDesignGui::ViewProviderPrimitive::unsetEdit() rely on parent PartDesignGui::ViewProvider to tidy up,
including closing the task dialog.
Reference:
This is the default stack call when closing a document while a PD task using PartDesignGui::Viewprovider is active:
Reduce cumulative error by holding onto the original point in a sequence
of linear optimizations. In testing, this fixes artifacts I have seen on
very finely sampled paths with very gradual curvature.
Further improvements are needed for this optimization, but at least this
change avoids a regression over the status quo.
===========================================
fixes#4324
A multiline error message produces poor visualisation when used in the UI, while
there is no need for it to be multiline.
Slightly clean up the code by separating linear segment optimization
from gcode generation. While the current optimization is not very
effective once there is any kind of meshing noise, having a single
method performing the optimization will make it easier to tweak
tolerances or strategies.
Extend the work from #3496 to allow the safe optimization of more
complex step transitions.
- Use the actual safePDC path for short step transitions and breaks,
currently up to 2 cutter diameters. This value is chosen to cover
basically all typical end step-overs, including those with heavy skew.
Extending this much further (up to the break even point for a retract &
rapid) will need some careful thinking for multi pass paths.
- Coordinate offset tolerances with per-operation tessellation
tolerances, to avoid tessellation artifacts messing up paths by
causing false retracts. Such retracts can cause entire steps near
vertical areas to be falsely skipped, which would cause a major
deviation from the target model. By considering per-job tolerances, we
allow users to safely save computational resources by computing roughing
operations with lower precision, or selectively increase precision for
finish passes.
- Refine the default tessellation tolerance to GeometryTolerance / 4.
This makes sure that the job GeometryTolerance is respected by
operation defaults.
