Sketcher mini-features

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Sketcher mini-features

Post by DeepSOIC »

I had a similar idea, but a bit different. I wanted to introduce interactive locking, where selection would influence how things are moved around.

The idea was that if you select some stuff, that stuff will either move in sync if you drag any selected entity, or remain locked in place if you drag something that isn't selected.

I feel like what you are doing regarding relative locking may be better implemented in a form of a macro.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Sketcher mini-features

Post by triplus »

A lot of mini-thanks are in order i guess. :D

P.S. Using just Hide constraints terminology would work slightly better? As when translating the term driving i have a feeling all sorts of mini confusions could be the outcome.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher mini-features

Post by abdullah »

DeepSOIC wrote:I had a similar idea, but a bit different. I wanted to introduce interactive locking, where selection would influence how things are moved around.

The idea was that if you select some stuff, that stuff will either move in sync if you drag any selected entity, or remain locked in place if you drag something that isn't selected.

I feel like what you are doing regarding relative locking may be better implemented in a form of a macro.
I call firsties!! ;)

Now seriously, if you have a better idea I am fine with that. However I think I did not understand your idea. It would seem that interactive locking does not require you to hit the lock constrain button, does it? If it doesn't, then it is a complementary measure. I mean great for moving, but how many DoF does it have when not dragging?
triplus wrote:P.S. Using just Hide constraints terminology would work slightly better? As when translating the term driving i have a feeling all sorts of mini confusions could be the outcome.
I remember the old discussion that left everybody unsatisfied for opposite reasons (reference vs driven vs driving vs normal vs blue vs red). It is still today that I sometimes see (sic) when I read posts using the official terminology and everybody calls it unofficially a different name (I am the driving/driven guy, for others is red/blue, others prefer not to qualify them). The UI (look at the menu) says "driving" and "reference". This must have been translated somehow into French, German, Spanish, Russian, Japanese, Portuguese, Italian,... Sic erat scriptum. :)
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Sketcher mini-features

Post by DeepSOIC »

abdullah wrote:It would seem that interactive locking does not require you to hit the lock constrain button, does it? If it doesn't, then it is a complementary measure. I mean great for moving, but how many DoF does it have when not dragging?
Yep, it's a complementary thing.
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Sketcher mini-features

Post by triplus »

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). It is still today that I sometimes see (sic) when I read posts using the official terminology and everybody calls it unofficially a different name (I am the driving/driven guy, for others is red/blue, others prefer not to qualify them). The UI (look at the menu) says "driving" and "reference". This must have been translated somehow into French, German, Spanish, Russian, Japanese, Portuguese, Italian,... Sic erat scriptum. :)
Well luckily i wasn't referring to that old discussion. :D As there we where looking for a terminology solution for a different (new) thing.

The term constraint was already used before that discussion. The inconsistency is what i wanted to point out. Everywhere else in the GUI it is called constraint ATM. In the dialogue you named it differently. And that additional part causes confusion by itself in my opinion. And when translated good luck with expecting anything reasonable to came out of it.

P.S. You can try it out yourself if you want. How would the term "driving constraint" be translated to your language? Does it make sense when translated? Compared to just translating the term constraint?
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher mini-features

Post by abdullah »

triplus wrote: The term constraint was already used before that discussion. The inconsistency is what i wanted to point out. Everywhere else in the GUI it is called constraint ATM. In the dialogue you named it differently. And that additional part causes confusion by itself in my opinion. And when translated good luck with expecting anything reasonable to came out of it.
Not sure I understand. Are we talking about "driving constraints"?

If yes, take a look:
DrivingReference.png
DrivingReference.png (103.26 KiB) Viewed 1565 times
triplus wrote:P.S. You can try it out yourself if you want. How would the term "driving constraint" be translated to your language? Does it make sense when translated? Compared to just translating the term constraint?
Just for fun:

Sketcher_zh-TW.ts: <source>Toggle reference/driving constraint</source>
Sketcher_zh-TW.ts- <translation>拘束於參考及一般模式切換</translation>
Sketcher_uk.ts- <translation>Перемкнути режим обмеження в посилання/водіння</translation>
Sketcher_sl.ts- <translation>Preklopi osnovno/gonilno omejitev</translation>
Sketcher_pt-PT.ts- <translation>Alternar entre restrição de referência/mandatória</translation>
Sketcher_kab.ts- <translation>Bascule entre contrainte référence/pilote</translation>
Sketcher_ja.ts- <translation>拘束の参照/能動を切り替え</translation>
Sketcher_it.ts- <translation>Vincoli Guida o Definitivi</translation>
Sketcher_hu.ts- <translation>Referencia/megvezetési kényszerítés ki-/ bekapcsolása</translation>
Sketcher_fr.ts- <translation>Bascule entre contrainte référence/pilote</translation>
Sketcher_gl.ts- <translation>Alternar constricións fixas/guiadas</translation>
Sketcher_es-ES.ts- <translation>Alterna restricciones de referencia</translation>
Sketcher_de.ts- <translation>Umschalten auf steuernde Bemaßung</translation>
Sketcher_cs.ts- <translation>Přepne refrenčí / řízenou vazbu</translation>

The other languages do not have a finished translation.

From the languages I more or less can understand or at least figure it out. German went for "toggle driving constraints", Spanish for "toggle reference constraints", Galician went for "toggle fixed/guided constraints", French for "toggle between reference and driving", Italian for "Guided/definitive constraint", Portuguese for "toggle between reference constraint or obligatory/driving".

Google translate helps here:
zh: "Constraints in reference and general mode switching"
uk: "Switch Mode restrictions in link / driving"
sl: "Switch base / driving restrictions"
ja: "Toggle constraint reference / active"
hu: "Reference / guiding force on / off"
cs: "Switches refrence / controlled bond"

It is quite fan that some languages went just for "driving", others with "reference" and yet others with both. Kudos for those translators that manage to translate "driving" in languages where a literal translation of what you do in a car makes no sense at all. I do not know about the quality of Google translate translations, but the idea of the Chinese translator seems in line with what you say "general mode constraint". Japanese translator choose something like "active constraint" which I find nice (enforced constraint?).

BTW, there is another appearance in one settings menu for driving constraint color.

I also found some language inconsistencies in English:
"Non-driving Datum color"
"The color of non-driving constrains or dimensions in edit mode"

Probably in the Settings of the Sketcher, as they are colors. I will fix them for consistency.
User avatar
microelly2
Veteran
Posts: 4688
Joined: Tue Nov 12, 2013 4:06 pm
Contact:

Re: Sketcher mini-features

Post by microelly2 »

If a triangle is defined by the lengths of the sides, these lengths are the drivers
and the angles depend (are driven).

In Sketcher the lengths are the red and the angles the blue constraints.

When I configure this sketch by expressions or by setting datums from outside,
the lenghts are set that means for me driven.

The object which is used in the expressions is the driver. Its parameters can be
red or blue ones.

So driver and driven are roles in different contexts. So my vote is to use red/blue constraints.

If red and blue are not the common understandable words - red is a constraint and blue is a depending value, in German "Einschränkung" and "abgeleitete Werte".
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher mini-features

Post by abdullah »

Another mini-feature.

I have always been annoyed that when I want to adjust a dimensionally constrained line, I toggle it to be a reference constraint, I drag the point, then I toggle back to driving, then I adjust the value to a reasonable number of decimals.

Now if you double-click on a reference constraint it automatically is converted to driving and the dialog to set a value appears.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Sketcher mini-features

Post by abdullah »

microelly2 wrote: When I configure this sketch by expressions or by setting datums from outside,
the lenghts are set that means for me driven.
So a manager that is a subordinate of another higher hierarchy manager stops being a manager.

I understand what you say, but in your example, the blue constraints are the worker, the red constraints are the supervisor, the expression cell in the spreadsheet is the manager of the supervisor and if that cell depends on 7 other cells you may reach the CEO, which somehow is also a subordinate of the board... it is potentially never ending (well it must end, but it can be a very long chain of command).
microelly2 wrote:If red and blue are not the common understandable words - red is a constraint and blue is a depending value, in German "Einschränkung" and "abgeleitete Werte".
So if we do not go for red and blue, red is a constraint (though it acts as driven from an expression point of view) and blue is a depending value (while the red constraint that depends on an expression is also a depending value).

It was a loooong polemic discussion at the time with a king Salomon kind of outcome (and note that I perceive as negative this kind of outcomes) and we did not have expressions back then.

I can agree that red and blue is probably the only way so far of not falling into any terminology trap (and there is merit there).

However, it sounds to me unsophisticated. In any case, that would work only because you and me, we know what they actually are, because if you would ask people around, probably you would get something like "red" means "stop", "do not trespass", "forbidden" and blue maybe obligation or information. It will not work that well for daltonic people or those concerned with style which probably use another different colors, as they can be changed in the settings. Not that I want to reopen that old discussion, but I am still to see somebody coming with a solution that when looked at by anybody, we would say: "oh god! finally! how is it that we did not come with such terminology earlier?"
triplus
Veteran
Posts: 9471
Joined: Mon Dec 12, 2011 4:45 pm

Re: Sketcher mini-features

Post by triplus »

abdullah wrote:Not sure I understand. Are we talking about "driving constraints"?
I wasn't aware there actually is one place in the GUI the term driving is being used. Likely using "Toggle constraint" instead would make more sense in the first place but nonetheless the term is used! ;)

@microelly2

I mentioned this small detail as i thought the term driving was only used in code until now. But as it propagated to the GUI in the past already. That i guess is more or less a done deal. The main "problem" i guess is when some term gets used by developers (as the term driving is used in the code) it will propagate to the GUI. And that is not always necessary the best outcome. But being involved in a few of such discussions in the past i learned that it is hard or better nearly impossible to do anything about it.
abdullah wrote:It was a loooong polemic discussion at the time with a king Salomon kind of outcome (and note that I perceive as negative this kind of outcomes) and we did not have expressions back then.
There where all sorts of things going on back then. The outcome was in my opinion such that it allowed evolution in multiple areas. And that happened and i am glad it did. Things evolved and i guess discussions don't need to (always) be polemic anymore just to be polemic. That counts as a positive thing in my book. Back to terminology challenges of today:

From the user point of view i don't see why the term Constraint should need any additional explanation. It works and it worked in the past. If the Reference Constraint term is problematic to some i don't feel changing the term Constraint will fix that. Instead just rename Reference Constraint to something else. Like for example Dimension. And that is that.

P.S. Beyond stating that and providing additional suggestion i don't really care. ;)
Post Reply