GNOME Bugzilla – Bug 300363
[ARITH] calculator's thousands separator does not work always
Last modified: 2008-09-23 11:22:05 UTC
Distribution: Debian 3.1 Package: gcalctool Severity: normal Version: GNOME2.10.0 unspecified Gnome-Distributor: Ubuntu Synopsis: calculator's thousands separator does not work always Bugzilla-Product: gcalctool Bugzilla-Component: general Bugzilla-Version: unspecified Description: Description of Problem: calculator's thousands separator only works on result, not on initial values users enter. Steps to reproduce the problem: 1. start gcalctool, then turn on thousands separator 2. type 10000000 Actual Results: 3. look at the pretty 10000000 (and guess what that number is) Expected Results: to see 10Â 000Â 000 find the answer of 10000000+1 to see how it should look like: 10Â 000Â 001 How often does this happen? always Additional Information: ------- Bug moved to this database by unknown@bugzilla.gnome.org 2005-04-12 13:08 ------- Unknown platform unknown. Setting to default platform "Other". Unknown milestone "unknown" in product "gcalctool". Setting to default milestone for this product, '---' Setting to default status "UNCONFIRMED". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.
Which version of gcalctool are you running? Help->About from the menu bar should tell you this?
what comes with ubuntu: 5.5.41
Reassigning to Sami as this appears to only be a problem in arithmetic operator precedence mode.
I am using gcalctool 5.7.29 (Gnome 2.13.91) and have the same problem...
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/gcalctool/+bug/44756 "The calculator, Gcalctool 5.6.31, has a minor bug. The menu option "View, Show Thousands Separator", often doesn't work. Its a bug in toggling this option on and off. As well as often failing to turn this mode on, it also can fail to turn this mode off. If I use the keyboard shortcut, ^K, this also fails to work. No, on second thoughts, perhaps its not a bug, it just looks like one. It just doesn't behave the way I expected it to. I've had a further look at this, and now I'm not sure if its a bug, or just unexpected behaviour. If I enter a number, then select the option to Show Thousands Seperator, it doesn't change how the existing number is displayed. So I thought that the "Show Thousands Separator" mode was not working. But if I press the "=" key then it correctly shows commas in the number. This may not count as a bug. But I had difficulty turning on this mode, because I saw that the existing number had not changed, (commas were not added to it), so I thought it was not working. I realise that when the user enters a number, the program can't add commas yet, because it doesn't know the user had finished entering the number until he presses "=" or some other operator key. But when I selected the option to "Show Thousands Separator", I expected the number currently being displayed by the calculator to change, at once. Perhaps it should be changed to do so. Your comments are welcome on this. Should the calculator have this small change made to it?"
In a general case the fix would be to have a parser which could identify all numbers from the expression and do the conversion. The problem is that the expression is basically a text string which can contain an arbitrary expression. I agree that currently the operation of "Show Thousand Separator" is very confusing, that is, not usable at all. I think the proposed fix would be a good idea, but I am not sure if it's trivial to make.
I think the behaviour of the calculator is reasonable. The problem is that it differs from the expectations of the users. One way to solve this problem is to change the expectations of the users. When the user selects the option to use the "thousands seperator", a message-box could pop up, with a message like this :- 'Commas will be added to any number over 999, but not until you press the "=" key or an operator key. To see the commas immediately, press "=". ' I think this is a good solution. It solves the problem opened by Sven, and it also solves the problem opened by me, quoted by Sebastien.
One alternative would be to have a short statusbar message telling the same. Any ideas about what the message could be? Statusbar wouldn't interrupt the user in the way that a message-box does.
Adjusting summary to reflect this is only a problem in arithmetic operator precedence mode.
Setting up Hungarian locale results in an even more confusing behaviour. Decimal point (comma) is for specifying decimal fractures, dots can be used for (in fact should be used according to the official rules). However, * 10000 (i.e. 10^4) is shown as 10,000 that is 10. Should be 10~000. * 1000000 (i.e., 10^6) is shown as 1,000.000 what is real confusing and very hard t o interpret. Should be 1 000 000.
I've merged all the thousands separator bugs into bug 527669 with a recent patch that appears to have fixed most of these problems. Thanks if you took the time to make a patch, I reviewed them but unfortunately none of them fixed all the problems simultaneously. Please test the patch and raise any issues in the new bug. Thank you. *** This bug has been marked as a duplicate of 527669 ***