GNOME Bugzilla – Bug 311307
gcalctool accepts keyboard input for buttons which are disabled.
Last modified: 2005-09-12 17:04:32 UTC
Please describe the problem: i'm using ubuntu 5.04, with gcalctool 5.5.41-0ubuntu1 In scientific view, some buttons tend to be disabled (grayed out) based on what numeric base you've selected. This is good. However, the keyboard isn't treated comparably. For example, pressing 8 and 9 on the keyboard when in octal mode actually enters (meaningless?) characters in the view pane, despite the "8" and "9" buttons being grayed out on the GUI. Steps to reproduce: 1. launch gcalctool 2. choose "View|Scientific" 3. switch numeric base to "Oct" 4. press '8' on your physical keyboard (not through the GUI) Actual results: the symbol '8' shows up in the View pane, despite not being a valid octal character Expected results: i'd assume gcalctool should either silently ignore the keypress or beep to indicate it is invalid. Does this happen every time? it happens every time. Other information: on a mixed debian etch/sid system with gcalctool 4.4.20-1, i get beeps when i press invalid keys, so this seems to be a regression.
Confirmed with gcalctool 5.6.24 on Ubuntu Breezy. However, gcalctool seems to convert the invalid numbers to the selected base on the fly, so this may be a feature instead of bug. But then why gray out the buttons if they still work?
Thanks for looking into this (and bug 311306) so quickly! I see what yer saying about it as a "feature", but i don't know if it's actually a feature that you'd really want permanently enabled, though. it is not clear to me that there's an unambiguous way to convert such invalid input. for example, if i type A0 when i'm in decimal mode, should gcalctool only convert the invalid digits while assuming that the radix always matches the explicit base (which results in 100 in decimal)? or should the program just assume that i was entering the entire number in hexdecimal initially (which would convert to 160)? How would you tell the difference? The former method is at least well-specified, i suppose, though it feels a lot like someone saying "eleventy-seven". i think gcalctool would be better off only allowing unambiguous input unless you want to add a "guess what i'm thinking" mode in addition to Basic/Advanced/Financial/Scientific! Thanks for a cool tool!
Hi Daniel, Teppo. Again, I've cc:'ed Calum for his views on this. Personally, when you are in a specific base, then you shouldn't be able to type in the other numeric values that aren't applicable to that base, but I'll adjust to whatever Calum thinks is best.
This is only a problem if you have View->Use Arithmetic Precedence set, so reassigning to Sami as this is his code. Sami, the fix here is to not allow inappropriate numeric values for the current base to be entered, or to indicate that the user has entered an invalid expression. I prefer the former, but I'm not sure that the parser (as currently implemented) can do that.
Yeah, I agree with the general feeling here... even ignoring the usefulness or otherwise of the 'feature' (because thinking about that made my head hurt :), if a button's greyed out, you just shouldn't be able to activate it from the keyboard.
Created attachment 52135 [details] Fix for the problem. Fix from Sami for the problem.
Created attachment 52137 [details] Proper fix from Sami for the problem It really helps if you attach the correct patch.
Changes checked into CVS HEAD. Calum, if you feel the wording of the status error message "Invalid number for the current base" should be adjusted, just let me know. Version number in configure.in changed to 5.7.0. Thanks!