GNOME Bugzilla – Bug 172704
Accuracy keyboard shortcut broken
Last modified: 2005-04-13 17:52:45 UTC
Please describe the problem: Steps to reproduce: Choose hex mode. Press "a" Actual results: Hex numbers become greyed out. Next digit pressed sets accuracy, but there is no indication that this is the case. The accuracy radio button menu is not updated. Expected results: Either: In hex mode "a" and "A" would both insert the hex digit "A". Or: A status bar would indicate that the next digit will set accuracy. The accuracy radio button menu is updated. Does this happen every time? Yes Other information: (As an aside, Gcalctool has an amazing number of shortcuts. So many in fact that it's really easy to make mistakes - most keys seems to do something without indication of whats going on)
Cc:'ing Calum, my HCI person as he was involved in the earlier reversal of the hex key shortcuts. See bug #118826. When the work for that bug report was integrated, the keyboard shortcuts for the six hex. digits were changed to "A" to "F". The functions that previously used those letters have been reassigned to their lowercase equivalents. These were: Accuracy (now "a") Change Sign (now "c") Double-declining depreciation (now "d") Exponential (now "e") User-defined functions (now "f") I think you second suggest solution: A status bar would indicate that the next digit will set accuracy. The accuracy radio button menu is updated. is the best we can do here without a complete rework of the all the gcalctool keyboard shortcuts. Calum?
Sounds like another reason for making arithmetic preference mode the default (and only) option... when you press 'a' with that mode active, you get 'Acc' in the display, rather than the hex buttons greying out... Seems to me the right solution here, though, would be to pop up the 'Acc' button's dropdown menu when you pressed 'a'-- then it's perfectly obvious what has happened, and how to proceed. A keyboard shortcut would normally behave in the same way as clicking its equivalent button, so there's probably no good reason why this one shouldn't. If we're stuck with status bar solution, though, I'd suggest something like 'Now press 0-9 to set accuracy, or Esc to cancel'. You could probably also argue that the additional greying-out of the hex buttons is unnecessary-- there are lots of other buttons you can press after 'a' that aren't valid in terms of setting the accuracy either, but they're not greyed out-- they apparently just cancel the 'set accuracy' directive (although it might be nicer if they just did what they usually do as well). <As an aside, there seems to be a small bug with the Acc menu stuff-- if I press a-3, then look at the Acc menu, it's set to 'Other (3)', rather than '3 Significant Places'...>
<Correction to aside... the 'Other' item is indeed updated to whatever I pressed, but '0 significant places' is selected...>
Oh, and I guess this implies that the other buttons with pop-down menus should work the same way, really... which means adding numerical mnemonics to C0, C1 etc. like you have on the Accuracy menu, so there aren't actually any more keystrokes involved for the user.
Thanks Calum. As i don't like bugs that are a catchall for several issues, I've filed bug #172869 (really an enhancement) specifically to handle the displaying of a menu and the selection of items from that menu. Not just for the Accuracy menu but for all gcalctool menus. This bug will be used to track the original problem and the final "aside" that Calum reported. I intend to fix it with a status bar message as described above. I'll make sure that the accuracy menu is correctly updated, and the hex buttons will no longer be grayed out. More to come...
Created attachment 39815 [details] Patch to fix these problem(s). I changed my mind. When the user now uses the keyboard shortcut for any of the gcalctool buttons that have a menu associated with them, that menu is now displayed. The user can use the arrow keys to select a menu item or the menu items shortcut.
Changes checked into CVS HEAD. Version number in configure.in bumped to 5.6.8.
*** Bug 172869 has been marked as a duplicate of this bug. ***
Created attachment 45224 [details] Further fixup/changes needed Couple further changes needed to get this fully working. - Adjusted the code to not try to display a menu when the user entered a left parentheses (another do_pending() type of operation). - Toggling the "Show Trailing Zeroes" operation via keyboard shortcuts, needed to clear the v-.pending flag. I've bumped the version number is configure.in to 5.6.10.