Ticket #3691 - Bug in draft scale. Only integers work

[Roy_043]

IMO it is wrong that the units setting has any impact on the scale input. It is actually not possible to set the number of decimals to zero. But even if that were possible, the setting should only influence how numerical properties and values are displayed, but not constrict user input.

[GeneFC]

IMO it is wrong that the units setting has any impact on the scale input.

I don't think that is the problem. The actual problem is that the "units" entry in preferences is not initialized in the default or reset "user.cfg" file. I don't know why the scale operation needs to look there, but it appears to restrict scaling if nothing is found in preferences.

(I just tried it both ways, with a populated preference file and without.)

Gene

[Roy_043]

@GeneFC:
I understand that you want to go into details, but fundamentally the scale operation should not be affected by the units setting. It should not 'look there'! And that, very much, is the problem I would say.

[GeneFC]

It is *not* affected by the unit setting, but if that setting has never been initialized the scale operation fails. A very common problem in all sorts of software.

It is a bug, but not because the units have any particular numerical value.

i did not write the code, so I do not know why it was done that way.

Gene

[HarryGeier]

Interesting, as these days i had a discussion on that matter.. Works for me, but not for a customers FreeCAD.

If someone starts to work on it, and improve it.. A box for the step increments , like in transform , would be very useful and allow smoother visual scaling.

harry

[Roy_043]

@GeneFC:
My point is that the units setting, initialized or not, and whatever its value, should not have any impact on the scale operation. IMO crisb's initial comment in the bug tracker: "Works as designed, OP might have set decimal places wrong" does not make sense.

[chrisb]

@GeneFC:
My point is that the units setting, initialized or not, and whatever its value, should not have any impact on the scale operation. IMO crisb's initial comment in the bug tracker: "Works as designed, OP might have set decimal places wrong" does not make sense.

... and I added another comment. What is it precisely what you want? The issue is described in detail, there is a workaround and it might get fixed someday.

[JAndersM]

I agree with Roy_043 that the scale factor should not be affected by the precision settings for dimensions at all. The best thing would be to enable expressions in the scale factor input (eg. to write 1/3).
I did change the code in my copy (DraftGui.py line 2296, 2303, 2310) to always use 6 decimals.
I have not figured out how to implement expressions in the input. If someone wants to point me to an example showing how to do this I will be happy to try implementing it and share the result if successful.

[Roy_043]

What is it precisely what you want? The issue is described in detail, there is a workaround and it might get fixed someday.

There are two potential solutions:
1.
The scale factor should stay linked to the number of decimal units. In the current implementation the link is incorrect, and this should be fixed.
2.
The scale factor should not be linked to the number of decimal units in any way as this is illogical. To fix things the link should be removed.

IMO only solution #2 is correct. Your and GeneFC's comments leave me in doubt about your opinions.

[chrisb]

This is my last try to explain it, because I have the feeling that except Gene the contributors havent carefully read what was posted and haven't thoroughly tested the current behaviour.

The scale factor is independent from the number of decimal units!

Let me give two examples to make it clearer:
If I set the number of decimal units to 2 the number of decimals in the scale factor is 6.
If I set the number of decimal units to 4 the number of decimals in the scale factor is 6.

Only the initialization is somehow linked to having edited the number of decimals in preferences once.