GNOME Bugzilla – Bug 131571
Constants are saved/loaded in a locale-dependent way
Last modified: 2004-12-22 21:47:04 UTC
The calculator has some problems with its constants. When first launched, the constant "pi" has the value of "pi" times 10^10. Probably gcalctool is confused by the current locale (de_DE, we're using the comma as decial separator here, not the point). The interpretation of the saved values seems to depend on the current mode (SCI/FIX/ENG) of the calculator, too. (Pretty confusing actually.) Sometimes the fractional part and exponent of the constants gets cut off ("pi" = 3, it was 3.1415E10 before). AFAICT, gcalctool should use a "C" locale when formatting/parsing its constants for saving and loading. Version: 4.3.35 (Debian Sid)
Is this problem still present in the latest gcalctool from CVS HEAD, or the last released tarball - v4.3.38, which can be found at: http://ftp.gnome.org/pub/GNOME/sources/gcalctool/4.3/ I'm hoping the fix to bug #131059 finally got constants doing the correct thing in non C locales. Looks like it's correct for initialisation, but not for loading/saving. Perhaps the save loc_radix/loc_tsep fix needs to be applied there. Adding Alexander to the CC: to confirm/reject this theory.
Created attachment 23393 [details] Potential fix for get_constant() put_constant() needs work.
Adding Toshi to the CC: Assuming this is still a problem in v4.3.38, then I think the get_constant() diff in the attachment will do the right thing getting the constants in, but the equivalent "converting constant string to C locale" first, before writing the constant needs to be done. I've added a line of debug just above where it needs to go. "init.value" in the put_constant() call needs to be wrapped in some routine that will convert that string to the C locale before it gets written out as a gconf resource. Does this sound correct?
I agreed with diagnosis of get/put_constant() problem. The problem may popup in case when user started gcalctool once in different locale (radix must be different). As it was told above/before better to do such things in terms of "C" locale. So patch looks really reasonable. I think put_constant() should construct (perhaps make_number()? wuth similar radix, tsep substitution) its own string value rather than store user input. Not sure but since the number of places where we need MPstr_to_num() to work different is growing. May be it's good idea to add some kind of special wrapper to this function and do swapping inside? One more thing to check. We shoud ask Sebastian to remove all gcalctool specific gconf entries before he retest with 4.3.38 version.
Now I tried 4.3.38. Here are the results: gconftool-2 --recursive-unset /apps/gcalctool gcalctool # German locale Constants are apparently in good condition. I now click the "Edit constants" menu item, and can see gcalctool writing the constants to gconf, e.g.: constant3value = 3,141592653 OK, now we contaminated gconf. Let's switch locales. LANG=C gcalctool The well-known \pi is now exactly three, no decimals. The other way works, too: gconftool-2 --recursive-unset /apps/gcalctool LANG=C gcalctool \pi is \pi, enter the "Edit constants" dialog, click OK. gcalctool # German locale \pi now is \pi * 1E10. The above patch by Rich Burridge fixes part of the problem: C -> de_DE works, de_DE -> C still doesn't, and de_DE -> de_DE is now broken, too *g* Two points: a) Should it even be possible to change built-in constants like "pi"? b) What about users which have messed their gconf keys up? Tell them to use gconftool?
Thanks for the feedback. As has been pointed out, it's probably best to get/set the constants in the C locale. I'll try to get to completing this next week. > a) Should it even be possible to change built-in constants > like "pi"? From the Con button menu, there is "Edit Constants". You can change the ten default constants from there. > b) What about users which have messed their gconf keys up? > Tell them to use gconftool? I can't think of an alternative. Note that the GNOME 2.5.X release(s) are by definition unstable, so this doesn't sound too unreasonable.
> From the Con button menu, there is "Edit Constants". You can > change the ten default constants from there. I know that. That's how I triggered the bug ;-) The question was more like "Why should anyone want to change the value of pi?"
Ah, okay. Well I'm tried to design (g)calctool so that you can do every action with keyboard shortcuts as well. So you typed something like "C" following by the digit 0-9 to load a constant. That mean you had to overwrite the ten default constants if you wanted to add your own. There probably isn't a need to enforce that anymore. It maybe better to keep the ten default ones and let you user defined ten (or more) of there own separately if they want to. As long as they can be got to by keyboard navigation.
Created attachment 23606 [details] Full fix for the problem (hopefully).
I've attached what I hope is a complete fix for this problem. Start with either the version in CVS HEAD (which is v4.3.39) or v4.3.38 from: http://ftp.gnome.org/pub/GNOME/sources/gcalctool/4.3/ then apply the latest attachment. As I'm running in the C locale, I'm not 100% this fixes the problem, but it doesn't seem to break it any worst for me. ;-) Feedback appreciated before I check it in. Thanks!
I've done a few quick tests and it seems to work well (applied to .38).
Thanks! I've checked the changes into CVS HEAD. I've updated the version number (v4.3.40). I haven't generated a new tarball though.