Problem with negative values in InputField

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
jriegel
Founder
Posts: 3369
Joined: Sun Feb 15, 2009 5:29 pm
Location: Ulm, Germany
Contact:

Re: Problem with negative values in InputField

Post by jriegel »

I also commit DevJohns patch to remove locale group characters from the InputField input. That means also the input field is from now on not locale agnostic anymore. If you type in e.g. "0.3" on a German locale the dot gets removed and the result is 3.0 float....

This whole thing leaves me a bit grumpy, since it forces locales again on number input on the Gui!

Another way would be to forbid group separators on the unit scheme.....
Stop whining - start coding!
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Problem with negative values in InputField

Post by wmayer »

This whole thing leaves me a bit grumpy, since it forces locales again on number input on the Gui!
Which is a good thing because all native Qt widgets do it this way.

Btw, the patch caused a regression in the method selectNumber(). Removing a group separator leads to problems because it doesn't select the full number if there is a group separator.
git commit b8df459 fixes this.
User avatar
DevJohan
Posts: 41
Joined: Sun Jul 13, 2014 2:36 pm
Location: Stockholm, Sweden

Re: Problem with negative values in InputField

Post by DevJohan »

Juergen, I don't think the input fields were agnostic in the way you describe since the remove group separators code was already there I just delegated every instance to a function that already existed and added some extra code for + and - signs.

I like Juergens idea of removing the group separators all together from the quantity input. The Quantity parser is a different thing than ordinary QtWidgets and being local agnostic as far as possible I think is a good thing. I like the idea that this input is as forgiving as possible when inputing numbers but this should only be allowed when no ambiguities or unexpected behavior arise.

This is a rough suggestion:
Don't allow ',' or '.' to be used as group separators, these have other meanings. Group separators if allowed at all should be something like '\'', '`' or why not ' ' ( e.g. allow "1`234.4", "1 234.5", "4'567,8" ?).
When it comes to decimal points allow ',' and '.' for simple numbers, however while inside a function argument or more specifically inside any type of parenthesis, only allow '.' as a decimal point since the ',' in this context is an item separator. ( at the moment what does "atan2( 45,56,78 )" or "atan2( 78,12.78 )" yield? )

That is my suggestion which is NOT 100% thought through.
/Johan
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Problem with negative values in InputField

Post by wmayer »

This is a rough suggestion:
Don't allow ',' or '.' to be used as group separators, these have other meanings. Group separators if allowed at all should be something like '\'', '`' or why not ' ' ( e.g. allow "1`234.4", "1 234.5", "4'567,8" ?).
Which symbol is used for a group separator is defined somewhere in the OS and Qt uses this symbol but you can't change this in Qt via its API. So, if you want to have another character you must change it in the OS.

Besides this the ambiguity only arises if both "," and "." appear in the input string passed to the quantity parser.
User avatar
DevJohan
Posts: 41
Joined: Sun Jul 13, 2014 2:36 pm
Location: Stockholm, Sweden

Re: Problem with negative values in InputField

Post by DevJohan »

wmayer wrote:Besides this the ambiguity only arises if both "," and "." appear in the input string passed to the quantity parser.
I don't understand which case you are addressing here.

In my opinion, this is FreeCAD and not a type setter. The locale is not used to analyze the string and doesn't need to be strictly followed when formating it either. That being said, adhering to the locale as far as is practically possible might be a good idea. Replacing '-' with the dash is more visually pleasing but not something you usually do when inputing a number. I think it would be fine to append group separators for clarity but I think adding '.' or ',' as group separator both make the value harder to decode for a human and adds unnecessary complexity to the parser. Take for example "12,566", this is either 12556 or 12.556 depending on locale and the same is true for "12.556". If you don't allow ',' or '.' as a group separator this is not an ambiguity.

I use computers with both English and Swedish locales and also different operating systems. Having FreeCAD treat input differently depending on which computer I use is in my mind a bad idea.

/Johan
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Problem with negative values in InputField

Post by wmayer »

I use computers with both English and Swedish locales and also different operating systems. Having FreeCAD treat input differently depending on which computer I use is in my mind a bad idea.
You mean you want FreeCAD to behave the same independent on the locale? Now I think this is a bad idea because than FreeCAD might behave differently to other applications which follow the locales on this computer and even worse might be inconsistent to itself. Qt widgets like QDoubleSpinBox also follows the system locales and I think our self-written widgets should have the same behaviour.
jmaustpc
Veteran
Posts: 11207
Joined: Tue Jul 26, 2011 6:28 am
Location: Australia

Re: Problem with negative values in InputField

Post by jmaustpc »

wmayer wrote:
I use computers with both English and Swedish locales and also different operating systems. Having FreeCAD treat input differently depending on which computer I use is in my mind a bad idea.
You mean you want FreeCAD to behave the same independent on the locale? Now I think this is a bad idea because than FreeCAD might behave differently to other applications which follow the locales on this computer and even worse might be inconsistent to itself. Qt widgets like QDoubleSpinBox also follows the system locales and I think our self-written widgets should have the same behaviour.
I agree with Werner. It makes sense to define local specifics at the operating system level. So all programs on the one O/S instance behave the same, or a close to the same as possible.

I use Australian style 1000 separators (comma) and decimal (point) a lot ....hardly surprising being Australian. :) It is unintuitive and frustrating for me when FreeCAD does not behave as I would expect e.g. the other way around, like the Germans or not recognising the coma thousand separator.

If you are changing computers and O/S with different locals then you should expect to have to think about that when you input data etc.. The same would apply to your spell checker and other programs.

Jim
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Problem with negative values in InputField

Post by wmayer »

It seems the patch caused another regression: viewtopic.php?f=3&t=7306

With the previous version you could enter

Code: Select all

App.Units.Quantity(".03")
but now it gives:
Python wrote: Traceback (most recent call last):
File "<input>", line 1, in <module>
ValueError: syntax error
User avatar
DevJohan
Posts: 41
Joined: Sun Jul 13, 2014 2:36 pm
Location: Stockholm, Sweden

Re: Problem with negative values in InputField

Post by DevJohan »

My point is that the QuantityParser as is stands today is more than just a facility to enter a number with digits. The QuantityParser handles both numbers, units and functions. You can for instance enter mod( numa , numb ) or atan2( numy, numx). In this way the QuantityParser is more than just a facility to enter a locale formated number.

When it comes to conformance with the usual workings of programs on the operating system I think this makes sense but not in all cases. For instance entering numbers with '.' or ',' as a decimal point is easiest if it conforms to your locale and to your numpad. However, when it comes to more precise tasks like entering a function there are certain standard ways of doing things which I believe is just as worth adhering to as the locale. Take the python console for example, there different characters have different meanings like ',' being a item separator and '.' being the decimal point and also having some other uses. If you allow functions in the QuantityParser (they are already there) it makes sense to follow the convention of most programming languages in common use and let ',' be the item separator and force the user to use '.' when writing a decimal number.

Regarding the group separators, how often do you enter them manually? Entering group separators is only valuable when entering a long number with lots of value digits. However many GUIs add these graphical entities because it makes numbers easier to read. Using ',' or '.' as a group separator makes the whole input system a mess if you don't want to force the user to abide to the locale exactly. If I had to enter dash every time I wanted to enter a negative value, this would be nonsense, it's not even on my keyboard. Visually I believe it's much easier to decode '`', ' ' or '\'' as group separators since they are clearly separable from the decimal character.

My basic point of view is don't mess with the work flow while still keeping the program sane and functioning. When entering a Quantity with a simple number and a unit, don't enforce a lot of rules, point or comma I don't care. When you enter more complicated expressions like functions and such you need to follow the standard way of doing things without ambiguities (think python/C++/Java/...).

I do think the Quantity parser should be locale agnostic as far as possible. Otherwise, like jriegel, pointed out in a PM some time ago, scripts and material libraries written using one locale wouldn't work on a computer using an other locale. Using the python console for example to enter ``App.Units.Quantity(".03")´´ would have different meanings depending on locale which would make scripts non-portable.

Kind regards,
Johan
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Problem with negative values in InputField

Post by wmayer »

Regarding the group separators, how often do you enter them manually?
Actually never but this is totally irrelevant. The group separator will be added by Qt when you enter e.g. the value "1234" and then use the up/down or wheel button.
Visually I believe it's much easier to decode '`', ' ' or '\'' as group separators since they are clearly separable from the decimal character.
This is your personal preference and you can change this in the settings of your OS.
I do think the Quantity parser should be locale agnostic as far as possible. Otherwise, like jriegel, pointed out in a PM some time ago, scripts and material libraries written using one locale wouldn't work on a computer using an other locale. Using the python console for example to enter ``App.Units.Quantity(".03")´´ would have different meanings depending on locale which would make scripts non-portable.
I would distinguish between what is written into the console (or a Python script) and an input widget. Everything what comes from the console or a script must be the "C" locale, i.e. "." is the decimal point and "," is the item separator. A group separator doesn't exist there. Here I fully agree with you to follow the convention of programming languages. So, this means the Quantity parser should be changed that it does NOT allow "," as a decimal point or group separator but only as an item separator.

However, what you type into an input field (e.g. the two classes InputField and QuantitySpinBox) should follow the locale settings. Internally the widget reads the entered text and passes a modified, "C" locale compliant text to the parser. The only problem I still see if you want to enter something like "atan2(x,y)" into an input field. Here it won't be clear what the meaning of a "," is but if the widget forces you to write ", " (i.e. comma + space) in order to be interpreted as an item separator you can handle this. This maybe isn't the nicest solution but how often does someone enter texts like this into an input widget?
Post Reply