This commit updates a *lot* of rather questionable path handling
logic to be robust. Specifically:
* All path operations go through Platform::Path.
* All ad-hoc path handling functions are removed, together with
PATH_SEP. This removes code that was in platform-independent
parts, but had platform-dependent behavior.
* Group::linkFileRel is removed; only an absolute path is stored
in Group::linkFile. However, only Group::linkFileRel is saved,
with the relative path calculated on the fly, from the filename
passed into SaveToFile. This eliminates dependence on global
state, and makes it unnecessary to have separare code paths
for saved and not yet saved files.
* In a departure from previous practice, functions with
platform-independent code but platform-dependent behavior
are all grouped under platform/. This makes it easy to grep
for functions with platform-dependent behavior.
* Similarly, new (GUI-independent) code for all platforms is added
in the same platform.cpp file, guarded with #ifs. It turns out
that implementations for different platforms had a lot of shared
code that tended to go out of sync.
Extrustion top and bottom faces require a normal to be present.
Before this commit, the normal is always taken from the assembled
loop; if the loop could not be assembled (i.e. the loop is broken
or not coplanar) the normal will be (0,0,0), which breaks the sketch.
Also, loops are not generated when generating the sketch
to determine its bounding box.
This may result in spuriously broken sketches when e.g. undoing
a change that has broken a loop.
After this commit, loops are generated when generating for bounding
box, and if the loop could not be assembled, then the workplane
normal is used. This still results in failures when there is
no workplane, but those cases should be quite pathological.
Before this commit, a same orientation constraint created with
a workplane selected would only remove 2 of 3 DOFs. After
this commit, it properly removes all 3 DOFs.
Before this commit, lathe groups had three DOFs, which of course
could not actually move. After this commit, lathe groups have
zero DOFs, as expected.
This bug was introduced in commit 6dced80.
Before this commit, DoLater would be run as an idle callback,
which (depending on system performance) could either result in
a half-regenerated sketch being displayed, with only the dragged
entity updated, or no regeneration whatsoever during the drag.
After this commit, the GTK behavior matches macOS and Win32 ones.
Hiding the menu bar was only supported on macOS, and it is inherently
troublesome to port because keyboard accelerators on Win32 and GTK
are inherently dependent on the menu bar being visible.
On top of that, it's not clear how to bring it back if it's hidden
by accident.
Before this commit, when a point is constrained to an entity (point,
circle, arc of circle or line segment) by clicking on it,
the resulting constraint is not necessarily satisfied, and the next
regeneration may place the newly constrained point somewhere other
than the intended position. After this commit, the parameters
are modified to satisfy the constraint.
Commit f5485cb and its ancestors add a parameter to some constraints.
This parameter must be materialized and assigned a non-zero value via
ModifyToSatisfy for the solver library to not make unnecessary
changes to the sketch during the initial generation. For this, we
represent it explicitly instead of using hc.param(0), such that
the materialized constraint does not conflict with any user-defined
ones.
This commit follows 41365c5, which enabled export of Z coordinate
by using POLYLINE instead of LWPOLYLINE. After this commit, only
the AcDb2dPolyline/AcDb2dVertex are used when exporting flat views,
which may improve compatibility with 2d design packages.
The existing code is horrible and needlessly platform-dependent.
Even worse, it causes a freeze on GTK. Instead of propping that up
with a few more crutches, just fix the root cause.
The somewhat confusingly named set_has_alpha() function does not
affect whether alpha can be used during rendering to the area.
Rather, it affects whether alpha will be used when composing
the contents of the area with the window underneath it.
Before this commit, if any rendering mode except "show all occluded"
is enabled, points can be highlighted for corresponding to a DOF
after "Analyze → Degrees of Freedom" but then promptly occluded,
which is confusing.
EvilSpirit
whitequark