GNOME Bugzilla – Bug 153854
loses state when changing view
Last modified: 2005-12-21 17:31:48 UTC
To reproduce: Do a calculation Change view (basic, ...) Result: Current calculation is lost. (changed to zero) Expected Calculation is not lost.
This is not a bug. This is deliberate. Some of the functionality that is available in Scientific or Financial mode simply isn't present in Basic mode, therefore the display is reset. Before I close this off as "not a bug", I've added my HCI person to the cc: for his comments on this.
I should have been more clear. Changing Basic->Scientific still resets even though it is a superset. I think the interface should be: if( representable in other view ) switch view else warn "changing views will lose your data" (with a never warn me again checkbox)
Well, the reporter does have a point... if the display is showing the *result* of a calculation, there's probably not really any need to clear it when switching modes unless any data loss would occur (e.g. if numbers are internally held to less accuracy in Basic mode than Scientific mode, or something)-- in which case you might just want to prompt for confirmation. Certainly you might also need to (for example) alert the user that you're changing the display from Hex back to Decimal when switching from Scientific to Basic mode, say (IMHO Basic mode should always be decimal-only), but you could probably just do that in the status bar or something. It's a different matter if you're part way through entering a calculation, and switch to a mode where some of the functions you've entered don't exist in the new mode. Then clearing might be the only reasonable option, but you might still want to ask for confirmation first to give the option of backing out.
All good points (from Stephen and Calum). Will work out what needs to be done and adjust accordingly. Thanks!
*** Bug 306159 has been marked as a duplicate of this bug. ***
Created attachment 48978 [details] Fix for this problem.
Changes checked into CVS HEAD. Version number in configure.in bumped to 5.6.21. I'll generate a new tarball in a few minutes. Note that this warning dialog will always be displayed irrespective of whether you are part way through a calculator or if the calculation is complete. Although it's possible to determine if the calculation is complete, with code that looks like: int complete = 1; /* Set if the user has completed a calculation. */ switch (v->syntax) { case npa: if (IS_KEY(v->old_cal_value, KEY_EQ.value[0])) { /* Calculation is complete. */ complete = 0; } break; case exprs: if (v->e.calc_complete == 1) { /* Calculation is complete. */ complete = 0; } break; } there are too many other things (edge cases) that, if all accounted for, make the code to handle this quite large. For example, going from arithmetic operator precedence mode to non-arithmetic operator precedence just before you change modes. It's just cleaner to always warn the user and then clear the display (noting that the warning dialog can be prevented from being displayed by checking the "don't show this to me again" box). Note also that changing modes will: * clear the display * set the base to decimal * set the numeric display to fixed * set the accuracy to nine places after the numeric point. * clear the display of the thousands separator * clear the display of trailing zeroes after the numeric point. and dismiss the register window if the new mode is Basic. If all that was mentioned in the dialog, it would get quite wordy. I'll make a note in the gcalctool documentation placeholder bug to get this added to the online help. In short, with the warning dialog now in place, the user should hopefully train themselves to only change modes when they are at a practical point to do so.
*** Bug 312416 has been marked as a duplicate of this bug. ***
*** Bug 314934 has been marked as a duplicate of this bug. ***
Most users will probably think something like "let me get back to work" and just click the check box, close it... and when they change mode sometime in the future... oups, calculations lost. Isn't there an easy fix that gets this "right" without showing a dialog most of the time? I.e. if a numerical value is shown in the display, do all or almost all, I don't know, of the stuff you do now but don't get rid of the value?
> I don't know, of the stuff you do now ... Comment #7 above pretty much summarises all the things that need to be handled.
So why not just do it and always warn the user and reset in all other edge cases (that would intriduce a large chunk of code that would make it hard to handle)? Wasn't that basically what Calum said in comment 3?
Hum, sorry, maybe it wasn't... you talk about cases that are hard to detect... But if the by far most common case is easy to detect then why not just do the conversion and skip the dialog in that case?
A valid point. Okay, I'll reopen it and see if I can indeed do that.
Created attachment 54790 [details] Improvements for non-arithmetic operator precedence mode.
If the user has completed a calculation and we are going to a new mode that is "compatible" with this one, then just change modes. Otherwise display a dialog warning the user that the current calculation will be cleared. Incompatible modes are: Scientific -> Basic Scientific -> Advanced Scientific -> Financial (unless we are in Scientific mode with Decimal numeric base and Fixed). These changes work nicely in non-arithmetic operator precedence mode. They've been checked into CVS HEAD and the version number in configure.in has been bumped to 5.7.12. For some reason, the display is still being cleared in arithmetic operator precedence mode, even though it's going through the right code path earlier. Keeping the bug open and transferring to Sami for further evaluation.
Created attachment 55337 [details] Improvements for arithmetic operator precedence mode. Similar change to that made on 15th November 2005, this time for arithmetic operator precedence (AOP) mode. Changes checked into CVS HEAD. Version number in configure.in bumped to v5.7.14. Still need to correctly handle this is AOP mode if it's the first thing the user does, so I'll keep the bug open for this.
Created attachment 56261 [details] Fix for AOP code: "first thing userr does is change mode" scenerio. Diff from Sami for the last piece of this fix.
Changes checked into CVS HEAD. Version number bumped to 5.7.18. Fix should turn up in the gcalctool tarball for GNOME 2.13.4.