GNOME Bugzilla – Bug 488796
The results display entry is too "entry-like"
Last modified: 2007-11-17 01:05:13 UTC
(New behaviors introduced by the Glade conversion.) Steps to reproduce: 1. Launch gcalctool and switch to Advanced Mode. 2. Click in the results display entry (edit bar?) just to the left of the "0" that is displayed. 3. Press Control+Tab to move focus out of the entry and back to the buttons. 4. Type 's' for sqrt. Expected results: The 0 would be replaced by "Sqrt(" Actual results: "Sqrt(" gets inserted before the "0" (Note, if you didn't do the initial clicking in step 2, you get the expected results.) 5. Click on the results display entry and start typing regular text (e.g. "hello world"), press Tab, type some more text. Expected results: You would be prevented from adding regular text into the display. Actual results: Whatever you type (including the Tab characters) get added to the display.
Note that these problems are not due to the recent change to using Glade, but were introduced with the recent changes for bug #326938. I think the code there needs to be tightened up. Rather than just evaluate the input line when the user presses Return, I suggest it tries to do the same as what it does for when the focus is not in the display area: process each character as it's typed and not allow characters that are invalid. The "bad expression" checking would also probably need to be turned off until the user did press Return because the input line would be in a state of flux while the user was modifying it. Transferring to Sami for further evaluation.
Created attachment 97558 [details] screenshots after pasting text into gcalctool Related to this issue.... The attached image shows what happens when you paste multiple lines of text into gcalctool. Left: The presence of all of the lines shoves the buttons off the screen. Center: After doing a select all and deleting the pasted text, the entry returns to normal, but the buttons do not. They remain tall and some fall off-screen. Right: Repeated the original exercise of pasting the multi-line text, but this time I pasted it quite a few times before deleting it.
Ugh. Note that this is only a problem in arithmetic precedence mode. The suggested approach to fix this is to evaluate the pasted input one character at a time rather than just append to the display. Sami, this would be in the exprs case statement in the get_proc() routine in gtk.c (about line 1738). Thanks.
Joanie, I think with the latest version of gcalctool in SVN trunk, things have improved. Could you comment and summarise what you still think are problems please? Note that if you've clicked in the display area, then focus moves out of that area, we are treating it as append-to-end-of-line. I note that the following could be used as a workaround: 1. Launch gcalctool and switch to Advanced Mode. 2. Click in the display area just to the left of the "0" that is displayed. 3. Press Control+Tab to move focus out of the entry and back to the buttons. 4. Type BackSpace 5. Type 's' for sqrt. In this case, the 0 is replaced with "Sqrt(". Sami, it looks like you should be able to detect if the display has been changed. If it hasn't, then when the user initially types something or clicks on a gcalctool button ("s" from the original set of steps to reproduce the problem), it should replace the contents of the display, rather than append to the end of the line. Thanks.
Following known issues exists with the hand-edit: 1. If display is focused, the states (including 0 state) are lost. 2. Result accuracy is lost, for example, 1/3 becomes 0.33333. 3. When display is focused, only keyboard works. That is, buttons only append the expression disregarding the cursor position. 4. Undo log is created even if display content is not changed for key presses. I think 2. and 3. are most severe. There might be a way to do something for 2. But 3. Can not be fixed. I suggest disabling gcalctool buttons while display is focused.
> But 3. Can not be fixed. I suggest disabling gcalctool buttons while > display is focused. We really need input from our HCI person here. Calum, could you please look back over the previous comments and suggest the best approach from a user perspective? Thanks.
Something strange has happened to SVN head. It seems gcalctool has lost the hand-edit ability. Some code is missing from SVN head. Editing logic is affected too, answer giving logic seems to be broken.
This is mentioned in comment #56 of bug #485919 http://bugzilla.gnome.org/show_bug.cgi?id=485919#c56 Robert, I believe you were going to look at a different approach for solving this problem? ...
Apologies for the reversion, see comment 26 in bug 326938.
Joanie, if you get a chance, could you try out the latest gcalctool functionality from SVN trunk please and see if it does the right thing? You'll note from my latest comment to bug #326938, that actually getting a result is now a problem, but lets fix that in the other bug. With this bug, I'd like to make sure all your concerns above are addressed. If they are, then we can close it off. Thanks!
Things are definitely much improved: I can no longer make the buttons so large that they fall off the screen. And I can't just type whatever I feel like (including Tab characters). I can still paste large quantities of text into the results display that, when removed, causes the buttons to be really, really large (but still all on screen :-) ). Maybe that's a WONTFIX (or WONTFIXANYFURTHER) as that is an edge case that most users won't attempt. So that leaves the following behavior which strikes me as odd: 1. Switch to advanced mode and click to the left of the '0' 2. Press Tab to move focus out of the display 3. Press S for Sqrt() Possible expected results: 1. Sqrt() 2. Sqrt(0) 3. Sqrt( 4. Sqrt(0 Actual results: 0Sqrt( (i.e. it's as if I clicked to the right of the '0' rather than the left)
I assume you mean "s" not "S'. Agreed. The initial 0 should be replaced with "Sqrt(" If I type "2" instead of "s", that certainly happens. Thanks.
Created attachment 99209 [details] [review] Fixes insert problem reported by Joanie Change behaviour from only using cursor when display has focus to always using cursor.
Created attachment 99212 [details] [review] Trim pasted text on newlines, replace tabs with spaces Stops the user from pasting inappropriate multi-line text
(In reply to comment #10) > bug, I'd like to make sure all your concerns above are addressed. If they > are, then we can close it off. Just tried the latest. Now all of my concerns are addressed. :-) Thanks guys!
Yeah, this is looking really nice. Feel free to close out this bug Robert. And thanks!