Rework of the material handling system.
This first part concntrates on a rework of the material cards.
Rather than use a fixed list of possible properties, properties can
be defined separately in their own files and mixed to provide a
complete list of possible properties. Properties can be inherited.
The cards then provide values for the properties. These can also
be inherited allowing for small changes in cards as required.
The new property definitions are more extensive than previously.
2 and 3 dimensional arrays of properties can be defined. Values
are obtained by calling an API instead of reading from a dictionary.
For compatibility, a Python dictionary of values can be obtained
similar to how it was done previously, but this is considered a
deprecated API and won't support the newer advanced features.
The editor is completely reworked. It will be able to edit older format
material cards, but can only save them in the new format.
For testing during the development phase, a system preference can
specifiy wether the old or new material editors are to be used. This
option will be removed before release.
Since Py3.11 the methods names __setstate__ and __getstate__ conflict with the method names added to the object class.
Thus rename them to 'loads' and 'dumps'
patches for #10459 and #10426...
a few small details escaped attention need to be fixed
😉
Removing unnecessary strings from Crowdin and improving typos.
Now all escaping required for the C++ code generation is done when the
.cpp/.h files are generated. Previously, only newlines were escaped
automatically. This was a) inconsistent and b) leaked c++ details into
the xml data.
In addition, the escaping is now done in one central place, harmonizing
the three previous implementations.
Pre-existing c++ escape sequences in the XML files have been replaced by
their literal equivalent so that the resulting python doc sting remains
unchanged.
* [Base] Add hasExtension for multiple values
* [Gui] Use hasExtension for multiple values
* [Drawing] Use hasExtension for multiple values
* [Fem] Use hasExtension for multiple values
* [Import] Use hasExtension for multiple values
* [Mesh] Use hasExtension for multiple values
* [Part] Use hasExtension for multiple values
* [TechDraw] Use hasExtension for multiple values
Relative paths appearing in Gmsh .geo files are relative to the .geo
file, not relative to the cwd when the gmsh executable was invoked. This
is okay when using absolute paths with the default "Temporary
directories" mode, but if one selects (in Preferences -> FEM) "Beside
.FCStd file", then relative paths are written to the .geo file. This
causes a (suppressed in FreeCAD output) warning from Gmsh that the brep
file is missing as well as the error:
Unexpected error when creating mesh: File to load not existing or not readable: partname/FEMMeshGmsh/BaseFeature_Mesh.unv
In this commit we just use relative paths, which is also convenient if
users move these files elsewhere (e.g., to work directly with advanced
features in Gmsh).
The load of the current file in test_open_head is fine, but
open_de9b3fb438 goes into an OOM even in huge (e.g. 10GB) systemd.
This probably needs a proper fix by upstream in regard to the migration
modules that load the old code, but until then (since the rest works on s390x)
this unblocks the package self-test in Debian & Ubuntu.
Patch by Christian Ehrhardt <christian.ehrhardt@canonical.com>.
This is Debian bug https://bugs.debian.org/984952 and Ubuntu bug
https://bugs.launchpad.net/ubuntu/+source/freecad/+bug/1918474.
Been part of the Debian edition of FreeCAD since 2021.
