- everything that is part of the drawing should be plain SVG (strictly following the SVG specification) to assure that every SVG program can handle it (e.g. Internet browsers).
The hatch patterns however contained old stuff like traces of Sodipodi that might be a problem in the future.
- negative scale and line width is not sensible and lead to strange effects thus set a minimum
- set the minimum reasonably above 0 since e.g. a hatch scale of 0.01 fills 8 GB RAM -> out of RAM error
- disable KeyboardTracking since we don't want a time-consuming recomputation while the user changes a value
This change was part of #2720 but has been skipped in order to not complicate a pending PR of an upgrade of the SMESH sources.
However, this other PR #2706 has been closed by its author.
Since this warning is reported on latest Fedora version using gcc 10 it will be fixed now.
avoid to crash the application when trying to create thumbnail from worker thread
avoid that application behaves weirdly when triggering an action update from worker thread
The Path Simulator was designed to handle canned cycle drilling operations, G81, G82, and G83, but it expects the industry standard continuous uninterrupted set of G8x commands until the operation is completed. A recent change to the Path Drilling operation adds commands that cancel each G8x command immediately after that command is used. This confuses the Path Simulation function and leads to visual artifacts when the simulation is performed.
G-code standards say that canned cycle cancellation can be accomplished by a specific G80 command or by any motion command in the set G0, G1, G2, or G3. This PR modifies PathSimulationGui.py to add recognition for canned cycle cancellation and resets the simulator to treat the next G8x command as the first element of a new series of canned cycles operations rather than a continuation of the previous series.
The existing dark themes all have fairly low contrast, which can make
text hard to read. This diff adds a variant of Darker-blue that
increases contrast between text and background.
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.
