If OpenSCAD or FreeCAD is set up to use pipes for communication, assume
it's because one or the other is sandboxed. In that case, OpenSCAD will
not be able to import the generated STL file from FreeCAD, so don't try
to run that test.
In 2021.01 OpenSCAD added the ability to read from stdin and write
output to stdout: this allows us to communicate with an OpenSCAD process
that does not have read/write access to the same directories that
FreeCAD does (for example, if one or the other is installed via a Snap
package).
This commit adds an additional preference to the OpenSCAD workbench
allowing the user to choose between communication methods, as well as to
optionally specify their own temporary directory for the data transfer,
for use in cases where their version of OpenSCAD is installed via Snap,
etc., but does not yet support the piped input and output.
Files opened by running `freecad xxxx.FCStd` or similar relative paths could not
be saved because of new code introduced to create parent directories. See
https://github.com/FreeCAD/FreeCAD/pull/4996#issuecomment-922370077 and
https://forum.freecadweb.org/viewtopic.php?f=13&t=62319&p=534156#p534156.
This commit resolves the issue by ensuring the parent path is absolute while
saving. We would probably like to make sure the file name is itself stored with
absolute path, but there's a few problems
1. There may be other occurences where files are loaded with relative paths. So
having a check here is a good idea.
2. Files opened by `freecad xxxx.FCStd` somehow don't have the issue where
renaming parent directory throws an exception on save. Instead the file is saved
in the new location.
- handle custom direction like all other directions
- allow to view the direction vector for all directions, but only to edit for custom
- fix enabling of the length alongNormal option
- also fix a translation issue
===============================================================
Forum test and comments:
https://forum.freecadweb.org/viewtopic.php?p=536445#p536390
What?
Showing/hidding a large amount of constraints is very time consuming
Why?
Because SketchObject Constraints property was being set for each individual constraint
Solution is to use the new setVirtualSpace overload taking a list or a tuple, so that all the
constraints are set in a single operation.
In a Debug system with the test of the forum the time taken by the operation is reduced
from 7 minutes to around 2-3 seconds.
This buffer application was removed in PR #4978 with removal of rotational code.
The buffer is required to provided adequate significant digit or rounding in later processing of envelope in Path.Area().
NOTE: I suggest separate `removalshape` envelopes be created without the necessary `buffer` adjustment to allow for usage of the `removalshape` for subsequent REST type operations.
