Sketcher Ticket #3793 - Reference Constraints toggle to driving on edit

[triplus]

'Reference' in FreeCAD stands for 'driven', not 'driving'. No need to write a book, just tell me what is FC terminology for 'driving' and I'll update.

Checkbox state determines that, therefore there is no need for an additional term. You are hence currently toggling in between reference constraint and constraint. Using the term Reference or Reference constraint for a label should therefore do.

[openBrain]

Checkbox state determines that, therefore there is no need for an additional term. You are hence currently toggling in between reference constraint and constraint. Using the term Reference or Reference constraint for a label should therefore do.

Using 'reference' means the logical is reversed, which IMO is counter-intuitive (but it can be discussed).
I prefer the checkbox to be checked when the constraint is driving. And it's not very proper to label the checkbox with 'Not reference'...
So what is the FC agreed term to specifically mention a driving constraint ?
Also notice that regarding consistency, when you use the ToggleReference button, the associated command in Python console is :

Code: Select all

App.getDocument('Unnamed').getObject('Sketch').toggleDriving(0) 

Thus 'driving' term is already there.

[triplus]

So what is the FC agreed term to specifically mention a driving constraint ?

Well, the most obvious one, constraint.

I prefer the checkbox to be checked when the constraint is driving.

Could be, but usually an inserted constraint is perceived as the default mode, toggling to reference constraint mode is what takes an additional action? Said that i am fine with whatever outcome happens next.

[chrisb]

Could you give some more details about what you think is cumbersome and could be improved?

To me it would be surprising (this work might be better suited than cumbersome) that a driven constraint changes to driving. But that is due to my different workflow and I can very well live with it.

Concerning the wording, this should indeed be discussed separately. Care to open a new topic?

[openBrain]

To me it would be surprising (this work might be better suited than cumbersome) that a driven constraint changes to driving. But that is due to my different workflow and I can very well live with it.

Today it switches to driving as soon as you edit it (even if you cancel). After PR it will switch only if you modify the value. And it will be visually displayed and can be canceled. So I think it's acceptable.

Concerning the wording, this should indeed be discussed separately. Care to open a new topic?

If you're OK, I guess we can continue on this topic as the original discussion was over. We won't hijack it.
According @triplus, it already has been discussed (at least driven constraint is called 'reference').
To me it's still a bit unclear and I see 2 possibilities :

1. Either we oppose 'Reference constraint' to 'Driving constraint'
2. Or we oppose 'Reference' to 'Constraint' (but in this case, term 'Reference constraint' should never be used')

PS : I set the PR in 'do not merge' state so we have time to discuss.

[triplus]

You have made a nice image here:



In short my proposal therefore is to change the label to say Reference and to uncheck it by default. Beyond saying that i don't plan to discuss this further or to oppose any potential different outcome.

[openBrain]

EDIT : saw a small issue. When editing a driven constraint, then making it driving with the checkbox, it's not possible to enter an expression (works with a value). To enter an expression it is a 2 step process, first making it driving, then entering expression. Will have a look at this on tomorrow.

Need some help here :

Ping

The main problem is that expression validation is embedded quite deep in the App part and I can't just remove the driving state check there. Also tweaking it isn't easy.
I could live toggling the driving state when it's changed in the edition dialog, but I don't really like it (beyond I have to check it won't clutter the undo stack transactions).
Do you see a reasonable solution ?
EDIT : I'd like something like tweaking the validation function to disallow expression if the constraint isn't driving AND the constraint isn't currently being edited...

[chrisb]

Concerning the behaviour of the new implementation you made the best of it.

1. Either we oppose 'Reference constraint' to 'Driving constraint'
2. Or we oppose 'Reference' to 'Constraint' (but in this case, term 'Reference constraint' should never be used')

I don't like the term "reference", although it is well possible that I fancied it in the old discussion - which I could not find. The idea was a constraint like thing which can be referenced. Good idea, but if I read it now it has a completely different taste. It is more like This is the reference, and others have to follow.

"Driving" and "driven" are a bit unhappy because the words are so similar, yet they describe exactly what happens. Since a "driven constraint" is in itself contradictory I would vote for

Driven dimension

to name the blue things looking like dimensions. They are dimensions, with the difference that the values are not set by the user.

[openBrain]

"Driving" and "driven" are a bit unhappy because the words are so similar, yet they describe exactly what happens. Since a "driven constraint" is in itself contradictory I would vote for
Driven dimension
to name the blue things looking like dimensions. They are dimensions, with the difference that the values are not set by the user.

I like "driving" and "driven" because ... they are quite standard terms.
I like your proposal too as only dimensional constraints are concerned. But regarding everything that should be changed (code, wiki, ...), I think triplus's proposal above is the best ATM.

[chrisb]

I think triplus's proposal above is the best ATM.

For the toggle - yes. And it would survive a later change of the wording. Nevertheless we should try to find clear notions, both newbie safe and power user safe. Then we can go ahead and change things step by step (or all at once).