Calculator widget - localization - decimal separator

[zz912]

Hello,

I would like to summarize my view on the localization of "Calculator Widget" #3500

At this moment, there is a rule for how the localization of decimal separators should look like:

2. Localization of float numbers in GUIs

Different locales use different decimal separators and thousands separators. Locale-specific string-to-float functions should be avoided as they may give unexpected results. (For example the text string "1.58" in de_DE will be converted to 158 by atof()). The following guidelines (based on avoiding ambiguity rather than on "correctness" in any specific locale) are suggested if parsing float to string and vice-versa:

In the case of input allow either comma (,) or point(.) as a decimal separator, but reject any input that has more than one of either. Space should be accepted but not required as a thousands separator.

In the case of display either use point (.) consistently or use the current localisation format consistently. The emphasis here being on "consistently".

Source:
https://linuxcnc.org/docs/devel/html/gui/gui-dev-reference.html#_localization_of_float_numbers_in_guis

I think we shouldn't discuss how to localize decimal separators at this moment.
We should only discuss whether some localization complies with the rules.

I know that every rule can be changed. But please don't suggest changes to the rules, because we will never agree. It took a lot of work to make the rules quoted above.

Sigma did a localization of decimal separator for Calculator widget:

I was happy with the functionality, but two problems arose:

1. I disagreed that this behavior is not default, but optional by value self.allow_dot_and_comma = True/False
2. At the time Sigma was doing this localization, there were no rules for localization of decimal separator. So there was a long debate about how it should work. This debate had no conclusion for Sigma. That's why this Issue was created.

My conclusion for Sigma:

1. Leave the Calculator widget - localization - decimal separator functionality as Sigma did it. Ideally, double-check that the functionality matches the rules above (mainly in DE localization).
2. Remove the value self.allow_dot_and_comma
3. The rules allow creating a GUI with decimal commas, but under the condition of format consistently. Therefore, displaying decimal comma in Gmoccapy is not allowed for consistency. Maybe someday some GUI will be created where the author will want to display the current localization format. Then it will be necessary to make the widgets variable. However, this situation has not yet occurred.

I would like ask the developers to accept or disagree with my conclusion. So that Sigma knows how to proceed further.

I would like "Calculator widget - localization - decimal separator" to be a model for how to do localization for all GUIs or widgets in LCNC. I made two widgets for LCNC (Little probe, Mesa screen) and I didn't know how to do localization correctly.

Maybe Sigma coding is not ideal, maybe it wouldn't be bad to have some common library/function:
/lib/python/common/
I can't judge that because I'm a hobby programmer. I'd be interested in the opinion of someone more experienced.

[hansu]

I would prefer the behaviour independent of the locale settings, which is mentioned in the docs:
(Not only for the calculator, for the widgets as well)

Input --> Display

10,123 --> 10.123
10.123 --> 10.123
10.12,3 --> error
10,1 + 10.2 --> 20.3

[gmoccapy]

I vote for the suggestion Hansu made.
That solution will enable every user to use his number block of the keyboard.

Norbert

[zz912]

I would prefer the behaviour independent of the locale settings, which is mentioned in the docs: (Not only for the calculator, for the widgets as well)

Input --> Display

10,123 --> 10.123
10.123 --> 10.123
10.12,3 --> error
10,1 + 10.2 --> 20.3

This description matches/describes the rules, so it's fine.

Question for @gmoccapy and @hansu. Do you agree to make this behavior the default? I want Sigma to remove self.allow_dot_and_comma = True/False .

Question for @Sigma1912 , do you need any more information to complete github.com//pull/3500 ?

[Sigma1912]

Input --> Display
10,123 --> 10.123
10.123 --> 10.123
10.12,3 --> error
10,1 + 10.2 --> 20.3

Isn't that what this does:
#3500 (comment)

[hansu]

Isn't that what this does:
#3500 (comment)

The mixed calculation? Yes.

[Sigma1912]

Remove the value self.allow_dot_and_comma

That means that default behavior of the calculator widget would change. I have already pointed out as to why I am not willing to do that:
#3500 (comment)

[zz912]

Remove the value self.allow_dot_and_comma

That means that default behavior of the calculator widget would change. I have already pointed out as to why I am not willing to do that: #3500 (comment)

Maybe the corruption of other-non maintanance GUIs would finally lead to their deletion. Bazinga (It is joke.)

I forgot your reason, it's been a while since you did that PR. I think it would be nice to state in the source code that self.allow_dot_and_comma is only there because it was tested for Gmoccapy, and that this variable may be removed in the future if other GUIs adapt.

[hansu]

That means that default behavior of the calculator widget would change. I have already pointed out as to why I am not willing to do that:

The calculator returns a float value (or int) so the interface to other GUIs using the calculator does not change.
The GUIs then can decide whether to display localized values or not, the calculator will accept dot and comma.

[zz912]

The GUIs then can decide whether to display localized values or not, the calculator will accept dot and comma.

This is not true. This is problem.

self.allow_dot_and_comma only switching between old functionality with atof, and new right functionality with replace(",", "."). Look in the code.

[gmoccapy]

@zz912 can you please specify?
I can not understand what is the problem with the interface between calculator_widget and GUI's.

The calculator does return a value, the GUI is responsible to handle that value. If an old not well maintained GUI is not able to handle this value, IMHO the "author" need to adapt his GUI or decide not to use the widget.

IMHO it is not good to try to be compatible with every GUI if you code a widget. Old code / sometimes even not used at all, should be removed.

Norbert

[hansu]

self.allow_dot_and_comma only switching between old functionality with atof, and new right functionality with replace(",", "."). Look in the code.

There is currently no "self.allow_dot_and_comma" in the Linuxcnc code