[PD]: Fix helix property visibility/writeability
* Hide irrelevant and internal helix properties
- The `HasBeenEdited` property is only used internally to check whether to
fill certain other parameters with initial values. So there is no need
show it in the property grid at all.
- The `Outside` property is only used in the subtractive helix and thus
hidden for the additive helix.
* Make derived helix properties read-only
Depending on the input mode, some properties are primary input, others
are derived. Prior to this change, also the derived properties have been
writable but their values are ignored and overwritten on the next
recompute. Now, when changing the input mode, only the primary input
props are writable.
* Reorder some helix properties
This change puts the reference axis and input mode at the top to become
more prominent. Only "Base" and "Axis" are higher in the list for
consistency with the other axis-based features.
Depending on the input mode, either `Growth` or `Angle` is used to create
a conical or flat spiral. The respective other can easily be calculated
to give consistent view. This is already done for the other properties,
e.g. `Height` is calculated from `Pitch` and `Turns`.
With this patch, the same is done for `Angle` and `Growth`.
Discretize of 0.0001 is okay for inches, but for metric <1microns would be quite small, this fixes some issues when generating paths for curves that look inward.
I found following post in the forum: https://forum.freecadweb.org/viewtopic.php?f=15&t=42755
I have experienced similar issues with other curves in my object.
Migrate to a UI that looks more like other software package managers, giving
more space to each addon by hiding the list when an addon is selected, and
providing a "back" button to get back.
Implements a two-style view option for the list of addons: expanded and
condensed, via a delegate that provides the drawing function for each row in
the table based on two different widget designs.
The pyrate has moved to salsa.debian.org, so this commit adds the
beginnings of support for those repos.The Markdown library is required
for nice rendering of repos that don't have a package.xml metadata file.
This shifts to use the model-view-controller pattern for the list of addons,
and moves to using a full model class rather than an indexed array for the
data storage and management. This enables much more information to be stored
as part of the new AddonManagerRepo data type. It now wraps the Macro class
for macros, supports Preference Packs, and provides access to the Metadata
object.
