armandas wrote: ↑Tue May 12, 2020 10:57 pm
- Store distance or angle as Dimension2.
adrianinsaval wrote: ↑Tue May 12, 2020 11:29 pm
Can the dimension be dynamically changed to go from mm to deg and back?
armandas wrote: ↑Wed May 13, 2020 3:13 am
That's what I'm interested in too. Alternatively, the input field could be dimensionless and the code would treat the value as needed.
I have not seen properties changing type dynamically. I do not claim they do not exist. I just have not seen them.
The editors for properties in the property editor depend on the property types. If we use an adimensional property, we will not have the angle editor (degrees symbol) or the dimension editor (mm) when editing.
I would start under the assumption that method1 (distance-angle) will use two properties of those types and method2 (distance-distance) will use two properties of the dimension type. Still method3 (distance, the one previously existing in PD) would use only one distance property. The default, I think, should be method3, because it minimizes the surprise of a user when loading a legacy file.
There are examples in FreeCAD PD of unused properties (for example a
pad has a second length that is only used when another property of enum type says "two dimensions").
We were assuming a difference with our situation, in that having a degree with a wrong value may reasonably be perceived as misleading. Hey I have distance1=5mm, distance2=10mm, but the angle property is shown as 45 degrees, how can this be? In the case of the pad is easier to ignore (oh yes this length2 is 100mm, but my pad only has one dimension). We were saying than then we will have to update some properties upon changing others. This behaviour we want to avoid (see also Werner's comment). However,
there might be a path in the middle: 1) Have 3 properties, 2) Dynamically change them so that the UI only shows the relevant ones, 3) Preferably, if possible setting the unused ones to non-persistent state, as why use up space in a file if it is not needed (this is a bonus requirement).
The alternative to this is to have different object classes. I think that for this specific situation it may be too much.
armandas wrote: ↑Wed May 13, 2020 3:13 am
n theory, it's just a simple calculation. Though implementing it using OCC API may not be trivial. I just checked how Solidworks does it, and actually, they ask to select the faces (makes sense, since you need to know the angle between the faces).
It's probably not the most important feature, I just mentioned it as an extensibility example.
Eventually, extending to a method 4 sounds plausible with a system with an enum property supporting different methods of creation.
When you are convinced of a technical solution for implementing the different modes, I would appreciate if we could fix the current master behaviour, so that it defaults to the previous behaviour, so that users of the development branch are not hindered when opening older designs and get the behaviour they expected (and obtained) when they created the model.