GNOME Bugzilla – Bug 469245
Hexadecimal input is not intuitive
Last modified: 2007-10-21 15:57:27 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/gcalctool/+bug/133915 "Binary package hint: gcalctool Lower case 'a' to 'f' characters are misinterpreted as shortcut keys(?) in Scientific mode instead of hexadecimal values. Uppercase 'A' to 'F' needs to be input to have it interpreted as hexadecimal value. If it's not a bug, then it's a highly annoying and misleading feature. Also the calculator accepts hex input even in Decimal mode. The user should at least be warned of this 'feature'. ..."
> Lower case 'a' to 'f' characters are misinterpreted as shortcut keys(?) in > Scientific mode instead of hexadecimal values. Uppercase 'A' to 'F' needs to be > input to have it interpreted as hexadecimal value. If it's not a bug, then it's > a highly annoying and misleading feature. Time to get out HCI guy on this to have a final say. See also bug #455889, where a similar topic came up. Adding Calum to the cc: > Also the calculator accepts hex input even in Decimal mode. > The user should at least be warned of this 'feature'. Please describe what you are seeing here. If you enter hex numbers in decimal mode in Operator precedence mode and hit Return, you get: "Invalid number for current base" in the status bar at the bottom of the window. What were you expecting to happen? Note that in left-t-right arithmetic mode in Decimal mode, you can't enter hex numbers at all, so perhaps you were expecting something similar?
reply from the ubuntu bug submitter "> Please describe what you are seeing here. If you enter hex > numbers in decimal mode in Operator precedence mode and hit > Return, you get: "Invalid number for current base" in the > status bar at the bottom of the window. > What were you expecting to happen? I would expect that there is no value input and symbol input from 'a/A-f/F' are ignored. I think when Hexadecimal input is available, it should take precedence over features like Function editing and Accuracy setup that are easily reachable through buttons but nowhere used as frequently as the Hexadecimal inputs. > Note that in left-t-right arithmetic mode in Decimal mode, > you can't enter hex numbers at all, so perhaps you were > expecting something similar?" Yes, but insensitive to the case of the entered symbol. (While it's logical that there is no 'capital 1', but why do I have to press Shift whenever I go over 9) In the end, sorry for the bug report, I should have RTFM'd more."
There is now a proposed solution to this for gcalctool for GNOME 2.21/22. There are two currently open bugs involved here: http://bugzilla.gnome.org/show_bug.cgi?id=455889 http://bugzilla.gnome.org/show_bug.cgi?id=469245 (and an old one - bug #118826). Before 24th September 2003, hexadecimal input used to be "a" - "f". This was changed to "A" - "F" because of bug #118826 http://bugzilla.gnome.org/show_bug.cgi?id=118826 The plan now is to change them back to "a" - "f". There are a set of other functions where the keyboard shortcut will be reverted to their original (pre Sept 2003) upper case values: [A] - Set accuracy [C] - Change sign [D] - Double-declining depreciation [E] - Enter an exponential number [F] - User-defined functions With copy/paste operations, where the user is pasting a string into gcalctool, the copy buffer will be iterated over. If an "A", "B", "C", "D" or "F" character is encountered, it will be converted to its lowercase equivalent. If an "E" is found, and the next character is a "-" or a "+", then it remains as an upper case "E" (it's assumed to be a possible exponential number), otherwise its converted to a lower case "e". Displaying of hex digits in the gcalctool display should still be in uppercase. Displaying of the "e" in an exponential number should still be in lower-case. In both left-to-right precedence and arithmetic precedence modes, if the user tries to enter a numeric digit that is incorrect for the current numeric base, then this shouldn't be allowed. This is already the case for left-to-right precedence. The gcalctool documentation (and tooltips) will be updated to reflect these changes. I think that covers everything raised in bug #455889 and bug #469245. If I've missed anything, or you see any problem with this proposed solution, please let me know. When the gcalctool 5.20.0 release is out the way, and the code has been branched, I'll start looking at what's needed to make these changes.
Created attachment 95297 [details] [review] Partial fix for this bug (and bug #455889). Sami, I've started on a patch to fix this bug (and bug #455889). The following has been done: The hexadecimal digits have been changed back to their pre Sept 2003 (bug #118826) values of "a" - "f". The following functions have also had their keyboard shortcuts reverted back to their pre Sept 2003 upper-case values: [A] - Set accuracy [C] - Change sign [D] - Double-declining depreciation [E] - Enter an exponential number [F] - User-defined functions With copy/paste operations, where the user is pasting a string into gcalctool, the copy buffer is now iterated over. If an "A", "B", "C", "D" or "F" character is encountered, it will be converted to its lowercase equivalent. If an "E" is found, and the next character is a "-" or a "+", then it remains as an upper case "E" (it's assumed to be a possible exponential number), otherwise its converted to a lower case "e". Displaying of hex digits in the gcalctool display will still be in uppercase. Displaying of the "e" in an exponential number will still be in lower-case. The following still needs to be done: 1/ Entering of lower-case "a"-"f" in Arithmetic Precedence mode currently results in a Malformed expression. 2/ Entering of Exponential numbers via copy/paste doesn't produce the correct result. For example, in arithmetic precedence (decimal mode), pasting "4000E+12" and pressing Return, results in "Invalid number for the current base". In left-to-right precedence (decimal mode), trying to paste "4000E+12" and pressing Return, just results in "40014" being displayed (no error or warning messages). 3/ In Arithmetic precedence, the hexadecimal digits "a"-"f" can be entered by the user as they are inputting a calculation. It's not until they press Return, that an "Invalid number for the current base" error message is generated. It should not be possible to enter a digit that is invalid for the current numerical base. This is how it works in left-to-right precedence. Could you look into fixing up these three problems? Please attach a new patch to the bug when you are ready. Thanks.
>With copy/paste operations, where the user is pasting a string into >gcalctool, the copy buffer is now iterated over. If an "A", "B", "C", >"D" or "F" character is encountered, it will be converted to its >lowercase equivalent. If an "E" is found, and the next character is a >"-" or a "+", then it remains as an upper case "E" (it's assumed to be >a possible exponential number), otherwise its converted to a lower >case "e". >Displaying of hex digits in the gcalctool display will still be >in uppercase. Displaying of the "e" in an exponential number will >still be in lower-case. I am confused, why is the copy buffer converted to lower case hex if displayed hex number (on gcalctool display) is uppercase? btw. How do you handle that the copy buffer does not do wrong changes? That is, for example, if copy buffer has "1 And 2", it does not change it into "1 and 2"?
> I am confused, why is the copy buffer converted to lower case hex if displayed > hex number (on gcalctool display) is uppercase? So that it can then be parsed correctly with: int ret = lr_parse((char *) text, v->MPdisp_val); (see line 2133 in get_proc() in gtk.c). That's how it seems to work nicely for left-to-right (npa) precedence. If you need to do something else for the arithmetic precedence mode, plus adjust the patch/code accordingly. > btw. How do you handle that the copy buffer does not do wrong changes? That is, > for example, if copy buffer has "1 And 2", it does not change it into "1 and > 2"? I don't. I posit that most gcalctool users will be cutting and pasting numbers and possibly simple arithmetic operations and not logical operations. I suggest we get this working for the majority of cases, then fixup the remaining problems. A possible solution to the "1 And 2" problem is to use either just lower case (not mixed character) tokens for operation such as this.
Created attachment 95475 [details] [review] Hex parsing support to LR-parser Currently LR-parser has no support for hex (upper or lower case) This patch brings support for uppercase hex symbols for LR-parser. By changing following line in the patch, the hex symbol case can be adjusted: HEXS [0-9]|[A-F]|" " lower case example: HEXS [0-9]|[a-f]|" " lower and upper case example: HEXS [0-9]|[a-f]|[A-F]|" "
I'd like for the arithmetic precedence mode to work the same way as the left-to-right mode. So if you type in "a"-"f" then you are entering hex digits (assuming that's allowed). If you type in an "A", then the Accuracy menu is displayed, and you can then select the menu item you want. Appropriate similar actions for the other keyboard shortcuts ("A" - "F"). At the moment, an "Acc" is being appended to the display area. That's not really useful. Also, if you are going to provide a fix for not allowing "a" - "f" to be entered unless in hex mode (and similar checks for other invalid input in the other numeric bases), then you will need to add an "immediate test check" mode to the code (rather than waiting for the user to press Return). Testing for actions like "display Accuracy menu when 'A' is pressed" can be added in there as well.
Created attachment 95736 [details] [review] More work on the problem. Sami sent me a new patchlet, so I've combined all three and obsoleted the previous two. There's still work to be done: 1/ Entering of lower-case "a"-"f" or upper-case "A"-"F" in Arithmetic Precedence mode currently results in a Malformed expression. 2/ Entering of Exponential numbers via copy/paste doesn't produce the correct result. For example, in arithmetic precedence (decimal mode), pasting "4000E+12" and pressing Return, results in "Invalid number for the current base". In left-to-right precedence (decimal mode), trying to paste "4000E+12" and pressing Return, just results in "40014" being displayed (no error or warning messages). 3/ In Arithmetic precedence, the hexadecimal digits "a"-"f" can no longer be entered by the user as they are inputting a calculation unless you are in hex mode (good!), but it's still possible to enter a digit that is invalid for the current numerical base (i.e. decimal digits in octal/binary modes and dec/oct digits in binary mode). This problem doesn't exist in left-to-right precedence.
Sorry, that first one should have read: 1/ Pasting of lower-case "a"-"f" or upper-case "A"-"F" in Arithmetic Precedence mode currently results in a Malformed expression.
Created attachment 96124 [details] [review] Patch that adds in copy/paste support for hex digits in arithmetic precedence mode. Updated patch from Sami. This fixes up: 1/ Pasting of lower-case "a"-"f" or upper-case "A"-"F" in Arithmetic Precedence mode currently results in a Malformed expression. The second problem: 2/ Entering of Exponential numbers via copy/paste doesn't produce the correct result. is going to be done as part of the fix for bug #439087. This just leaves: 3/ In Arithmetic precedence, the hexadecimal digits "a"-"f" can no longer be entered by the user as they are inputting a calculation unless you are in hex mode (good!), but it's still possible to enter a digit that is invalid for the current numerical base (i.e. decimal digits in octal/binary modes and dec/oct digits in binary mode). This problem doesn't exist in left-to-right precedence. And Sami is working on that. Thanks!
Created attachment 96132 [details] [review] Version of patch that adds in solution to problem (3) for arithmetic precedence mode. Incorporated in a new patch diff from Sami for part (3). Patch is close. At the moment, there are unfortunately regressions with entering exponential numbers in arithmetic precedence mode, so it's not ready for checking in yet.
Created attachment 96134 [details] [review] Revised version removing debug line. The remaining problem is to stabilize exponential number input in arithmetic precedence mode: If you look at the online help for gcalctool, there are four examples for entering exponential number, both for arithmetic precedence mode and four different ones for left-to-right precedence mode: Arithmetic Precedence. ---------------------- 12000000000 1 2 Exp 8 = -1200000000 1 2 +/- Exp 8 = 0.00000012 1 2 Exp - 8 = -0.00000012 1 2 +/- Exp - 8 = Left-to_right Precedence. ------------------------- 12000000000 1 2 Exp 8 = -1200000000 1 2 +/- Exp 8 = 0.00000012 1 2 Exp 8 +/- -0.00000012 1 2 +/- Exp 8 +/- At the moment, with the latest attached patch to bug #469245, the four arithmetic precedence examples are failing and the four left-to-right precedence examples are still working nicely. This is with entering everything using the mouse and the gcalctool buttons.
Created attachment 96337 [details] [review] Hopefully the final version.
Here's the ChangeLog entry for this: * help/C/gcalctool.xml: gcalctool/calctool.c: gcalctool/calctool.h: gcalctool/functions.c: gcalctool/lr_tokeniser.l: gcalctool/ce_tokeniser.l: gcalctool/gcalctool.1: gcalctool/gtk.c: gcalctool/ce_parser.y: With lots of help from Sami Pietila <sampie@ariana-dsl.utu.fi> Fixed bug #469245 – Hexadecimal input is not intuitive and bug #455889 – Copy/paste of lower case hex letter does not work. The hexadecimal digits have been changed back to their pre Sept 2003 (bug #118826) values of "a" - "f". The following functions have also had their keyboard shortcuts reverted back to their pre Sept 2003 upper-case values: [A] - Set accuracy [C] - Change sign [D] - Double-declining depreciation [E] - Enter an exponential number [F] - User-defined functions With copy/paste operations, where the user is pasting a string into gcalctool, the copy buffer is now iterated over. If an "A", "B", "C", "D" or "F" character is encountered, it will be converted to its lowercase equivalent. If an "E" is found, and the next character is a "-" or a "+", then it remains as an upper case "E" (it's assumed to be a possible exponential number), otherwise its converted to a lower case "e". Displaying of hex digits in the gcalctool display will still be in uppercase. Displaying of the "e" in an exponential number will still be in lower-case. The way to enter exponential numbers in arithmetic precedence mode has changed. The following four examples should show you the new correct syntax: 1 2 Exp + 8 = 1200000000 - 1 2 Exp + 8 = -1200000000 1 2 Exp - 8 = 0.00000012 - 1 2 Exp - 8 = -0.00000012 In both left-to-right precedence and arithmetic precedence modes, if the user enters a numeric digit that is incorrect for the current numeric base, this shouldn't be allowed and should not be entered in the display. The gcalctool documentation (and tooltips) have been updated to reflect these changes. Thanks to Sami for all the arithmetic precedence parts. Last patch has been committed to SVN trunk. It'll also turn up in the next gcalctool tarball (not sure when that is yet). Closing as FIXED. If you find any problems with it, please comment to this bug.
*** Bug 487782 has been marked as a duplicate of this bug. ***
The tooltip for the Change sign button indicates the shortcut is 'c' rather than 'C'.
Accuracy is wrong too. I'll open a fresh bug for those two. Thanks!