How is Scale calculated?

[Svarov]

All right, I’ll test it on weekends and report back here.

[Svarov]

I didn’t complete all tests, but I’ve already noticed one big issue. The “set_is_distance()” hint or something related to it doesn’t support locales properly. For example, my Windows machine is set to Russian locale and in it we use comma (,) as separator in floating-point calculations instead of dot (.).

Now Synfig converts every vector value to dot separated number on edit, e.g. 0.5 instead of 0,5 and it gets dropped to zero because Synfig cannot understand it this way. It’s quite confusing, isn’t it? Maybe video will illustrate it better.

Take a look at how editing floating-point number looks in Stable:

Notice that when I hit enter without editing value it remains the same.

Now look how the same thing behaves in Master:

Pay attention to the following differences:

• “1,000000” gets rounded up to “1” on edit
• The number separator gets immediately changed to dot (.)
• If you don’t change it back to comma (,) Synfig will reset it to zero, so 0.5 will become 0

This will confuse users because on every parameter edit they will have to retype both numbers (X and Y).

[rodolforg]

@Svarov

“1,000000” gets rounded up to “1” on edit

Yeah, I noticed that. The code was there before I touched it. I thought it would be better to show 1.0 than 1 though

@Svarov

The number separator gets immediately changed to dot (.)

Oh, I’ll investigate it! Here I use Portuguese (Brazil) locale and I have this same issue! Thanks!

[Svarov]

@rodolforg

I thought it would be better to show 1.0 than 1 though

I think it should show full floating number without rounding up like in all other Synfig nodes. You know, use the same algorithm of showing floating numbers, because consistency is good.

Here are results of a complete test:

Layers:

• Other → Plant → Gravity - gravity is a force, doesn’t make sense to convert it to pixels
• Geometry → Polygon → Vertices List - a standard list of vertices defining 2D coordinates, should be converted to specified Unit System
• Geometry → Outline/Adv. Outline/Region → Vertices List - a standard list of spline vertices defining 2D coordinates, should be converted to specified Unit System

ValueNodes (parameters in converters):
ValueNodes ignore measurement system. So if you apply converters to a parameter that has, for example, ‘px’ unit, then we got ourselves a mess like on a picture below. Not sure if this needs to be fixed, because converters can go very deep down depending on math formula and context.

The upper node has ‘px’ as unit but underlying has units so kinda confusing to user:

[BobSynfig]

@Svarov

• “1,000000” gets rounded up to “1” on edit
• The number separator gets immediately changed to dot (.)
• If you don’t change it back to comma (,) Synfig will reset it to zero, so 0.5 will become 0

This will confuse users because on every parameter edit they will have to retype both numbers (X and Y).

Good observation, this is a common issue in international development : Conversion
All the formats of numbers, dates, languages, code pages…
For consistency, everything must be “standard” internaly and converted for display in last instance (and converted back also)
How many times I heard complains in a former job (in an multinational company) when the employees were exchanging overseas localized as CSV (because it is “more simple”) instead of real Excel files

[rodolforg]

Thank you, Svarov!

@Svarov

I think it should show full floating number without rounding up like in all other Synfig nodes. You know, use the same algorithm of showing floating numbers, because consistency is good.

Well, I’d prefer to show as less useless zeroes as possible (both in view and edit widgets) rather 1.000000000000 lol : 1.2 instead of 1.2000000, -5.4543634 instead of -5.4543634000 , etc.

Anyway, I fixed the decimal point character (but not pushed to Github yet)

@Svarov

Other → Plant → Gravity - gravity is a force, doesn’t make sense to convert it to pixels

In fact, gravity is the directory AND intensity, but intensity seems to be the boundary the plant ‘grows’/‘falls’ (there is a green duck/handle to adjust it and you can see what I mean). So I think it should be using the Unit System.
In the picture below, it is the ‘gravidade’ parameter (sorry, it’s in my language).

@Svarov

• Geometry → Polygon → Vertices List - a standard list of vertices defining 2D coordinates, should be converted to specified Unit System
• Geometry → Outline/Adv. Outline/Region → Vertices List - a standard list of spline vertices defining 2D coordinates, should be converted to specified Unit System

Got it! Internally it’s called “point” so I didn’t catch it

@Svarov

ValueNodes (parameters in converters):

Ouch. Well, it works (bad) like that on 1.2.2 and 1.4.0 too. So I’ll try to fix it later, because it seems to be not trivial

[Svarov]

@rodolforg

Well, I’d prefer to show as less useless zeroes as possible (both in view and edit widgets)

Yeah, I agree as long as both view and edit widgets use the same algorithm and not like in gif above.

@rodolforg

In fact, gravity is the directory AND intensity

Oh, I see, it’s not really a gravity… Alright, but now I am thinking that it might be a good idea to rename this parameter to ‘Growth’ or maybe ‘Direction’, but it’s not that important.

@rodolforg

Well, it works (bad) like that on 1.2.2 and 1.4.0 too. So I’ll try to fix it later, because it seems to be not trivial

It does seem to be tricky. Don’t worry though, beginners don’t usually use converters and advanced users will be able to adapt or switch metric system back to units, so it’s not a major issue in my eyes.