Sketcher mini-features
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Sketcher mini-features
OK it's worth a try. When i select a single point and click on Coincident constraint. Pop-up is the outcome. Wouldn't it be better to do something useful instead. Like creating coincident constraint between the selected point and origin?abdullah wrote:A P.R. a day keeps the doctor away:
Re: Sketcher mini-features
I like the notion of driving vs. driven. To me it makes things immediately clear if I look at a sketch. If looking at a triangle (disregarding it's position on the plane for a moment) we have 3 lengths and three angles. We can use any three of them as driving constraints and the other three are driven. That's how the solver sees them. The System defined by the red constraints has to be solved.
However there is a third state not for the solver but for thre user, and that is how the red driving constraints are defined: It can be by inputting a value directly or by using an expression, where the latter can use additional external data. While it is still a driving constraint for the solver and thus for the current sketch it is something different for the user: And that's the point where I often would have liked to have an additional colour for expression using constraints like orange - which still has a considerable amount of red in it.
However there is a third state not for the solver but for thre user, and that is how the red driving constraints are defined: It can be by inputting a value directly or by using an expression, where the latter can use additional external data. While it is still a driving constraint for the solver and thus for the current sketch it is something different for the user: And that's the point where I often would have liked to have an additional colour for expression using constraints like orange - which still has a considerable amount of red in it.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Sketcher mini-features
Can be arrangedchrisb wrote:And that's the point where I often would have liked to have an additional colour for expression using constraints like orange - which still has a considerable amount of red in it.
Re: Sketcher mini-features
I looked for some reference (SW):
P.S. And having separate toolbars for each scope? That would in addition be more future proof as involved toolbars are getting a bit big? If not i am prepared to drive or make driven constraints if that makes other users happy.
- Constraints (Red/Driving Constraints in FreeCAD)
- Dimensions (Blue/Reference/Driven Constraints in FreeCAD)
- Relations (geometric constraints like for example Equality constrain in FreeCAD)
P.S. And having separate toolbars for each scope? That would in addition be more future proof as involved toolbars are getting a bit big? If not i am prepared to drive or make driven constraints if that makes other users happy.
Re: Sketcher mini-features
I'm sorry Adbdullah, but speaking for myself it is not what the debate was about.abdullah wrote:I remember the old discussion that left everybody unsatisfied for opposite reasons (reference vs driven vs driving vs normal vs blue vs red).
Driving/driven, normal/reference, I don't care, it's just semantics. What's at the heart of the problem is that as soon as a constraint is switched to reference, it plainly stops being a constraint. The fact that nobody seems to be acknowledging this simple evidence is utterly maddening to me.
Even if I know this may be fruitless, let's recap on the definition of what a constraint is:
https://en.wiktionary.org/wiki/constraint
So a reference constraint or a driven constraint is a contradiction in terms.Wiktionary wrote:Noun
constraint (plural constraints)
- Something that constrains; a restriction.
- (mathematics) A condition that a solution to an optimization problem must satisfy.
- (databases) A method that maintains database integrity.
Last edited by NormandC on Wed Apr 19, 2017 3:34 am, edited 2 times in total.
Re: Sketcher mini-features
"Sokath, his eyes uncovered!"triplus wrote:I looked for some reference (SW):
I guess it could make sense?
- Constraints (Red/Driving Constraints in FreeCAD)
- Dimensions (Blue/Reference/Driven Constraints in FreeCAD)
Re: Sketcher mini-features
The terminology problem was resolved in the GUI:NormandC wrote:"Sokath, his eyes uncovered!"triplus wrote:I looked for some reference (SW):
I guess it could make sense?
- Constraints (Red/Driving Constraints in FreeCAD)
- Dimensions (Blue/Reference/Driven Constraints in FreeCAD)
- Constraint
- Reference constrain
P.S. And as a plus we discovered Assembly relations (not constraints) are the correct thing to do. Makes me wonder why nobody nitpicked about that for all this years when it comes to the scope of Sketcher constraints that should actually be named Relations. And in addition note that driving/driven is what the current proposition is. Therefore change (if it happens) will still likely be a compromise. And users on the forum will still likely use whatever term they feel is appropriate.
Re: Sketcher mini-features
As for the short version:
My vote (if changing the current terminology makes sense due to lack of general consensus) goes to whatever solution gets the general consensus.
My vote (if changing the current terminology makes sense due to lack of general consensus) goes to whatever solution gets the general consensus.
Re: Sketcher mini-features
triplus wrote:Constraints (Red/Driving Constraints in FreeCAD)
Dimensions (Blue/Reference/Driven Constraints in FreeCAD)
Relations (geometric constraints like for example Equality constrain in FreeCAD)
As you both can imagine, I am not sentimentally attached to reference/constraint terminology. What I see today is that if we change terminology, there is a lot of places to update, not only the UI in the code, but also translations, wiki. It is not my work, to which I can commit, that we would be deciding, but the work of other people. That said:NormandC wrote:Driving/driven, normal/reference, I don't care, it's just semantics. What's at the heart of the problem is that as soon as a constraint is switched to reference, it plainly stops being a constraint. The fact that nobody seems to be acknowledging this simple evidence is utterly maddening to me.
It seems that we can agree, as a lesser painful compromise, that the "red" thingies are constraints and the "blue" thingies are dimensions. Then the toggling would be switching constraints to/from dimensions. The dimensions would appear in the constraint widget, where the widget may need to be renamed to "Constraints/dimensions" (this was an issue in our old discussion).
I have 2 points as for this discussion:
1. Is it ok, as a better compromise, that we rename the whole project to accommodate "dimensions" instead of "reference constraints", so that there is no need to qualify a constraint as driving or driven?. If yes: Does anybody object?, if no:
2. If I commit my work and time to effect the change in the repository. Who is willing to update the wiki and doing any other "non-repository" work? If there are volunteers for this work:
A plan is: I make the repository changes and volunteers update the wiki.
Let me know.