Bug 487566 - Kcalc doesn't chain result into next calculation anymore
Summary: Kcalc doesn't chain result into next calculation anymore
Status: REOPENED
Alias: None
Product: kcalc
Classification: Applications
Component: general (show other bugs)
Version: 24.05.0
Platform: Arch Linux Linux
: HI normal
Target Milestone: ---
Assignee: Evan Teran
URL:
Keywords: regression
: 487611 487772 488483 488660 488726 488852 489287 489339 489539 (view as bug list)
Depends on:
Blocks:
 
Reported: 2024-05-26 03:57 UTC by Tom Dzmelyk
Modified: 2024-07-19 02:12 UTC (History)
36 users (show)

See Also:
Latest Commit:
Version Fixed In: 24.05.2
Sentry Crash Report:


Attachments
KCalc 24.05.0 (61.82 KB, image/png)
2024-05-26 03:57 UTC, Tom Dzmelyk
Details
Kcalc 24.02.2 (61.21 KB, image/png)
2024-05-26 03:59 UTC, Tom Dzmelyk
Details
Proposed behavior (774.88 KB, image/gif)
2024-05-29 00:27 UTC, Gabriel Barrantes
Details
demo 2 (790.41 KB, image/gif)
2024-05-30 02:29 UTC, Gabriel Barrantes
Details
demo3 (1002.71 KB, image/gif)
2024-05-30 02:37 UTC, Gabriel Barrantes
Details
Demo 4 (372.76 KB, image/gif)
2024-06-05 20:50 UTC, Gabriel Barrantes
Details
then the switch of "repeat operation on every result " is not functional (208.05 KB, image/png)
2024-06-13 02:36 UTC, ihipop
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Dzmelyk 2024-05-26 03:57:45 UTC
Created attachment 169840 [details]
KCalc 24.05.0

SUMMARY

What used to work is that you could type `9x9` and press enter, and it would display 81, and you could then type `/3` and get 27, without manually typing the 81. Now the when you type 9x9 and press enter and then type `/3` and press enter it says input error.

STEPS TO REPRODUCE
1. Open Kcalc
2. Multiply 9 times 9
3. Divide by 3

OBSERVED RESULT
Kcalc says input error

EXPECTED RESULT
27

SOFTWARE/OS VERSIONS
Arch Linux
Plasma 6.1 beta


ADDITIONAL INFORMATION
Comment 1 Tom Dzmelyk 2024-05-26 03:59:19 UTC
Created attachment 169841 [details]
Kcalc 24.02.2
Comment 2 oldherl 2024-05-27 05:30:15 UTC
*** Bug 487611 has been marked as a duplicate of this bug. ***
Comment 3 Gabriel Barrantes 2024-05-27 22:27:06 UTC
This was done by design, I am not quite sure what people would prefer tho, we could add a config option to set this behavior.
Comment 4 guimarcalsilva 2024-05-27 23:44:36 UTC
(In reply to Gabriel Barrantes from comment #3)
> This was done by design, I am not quite sure what people would prefer tho,
> we could add a config option to set this behavior.

I don't remember ever seeing a calculator app in any platform not reusing the result from the previous calculation in a new one. Most people are used to that, so, in that case, I believe it would be simpler to just do that instead of adding an option. That is, unless there's a use case for not wanting to reuse the result of the last calculation.
Comment 5 fanzhuyifan 2024-05-28 01:48:15 UTC
The only problem I foresee is a conflict when users start a new calculation by pressing/clicking the minus sign. It could either mean use the old result and subtract, or the negative sign in starting a new calculation. The calculators I have used typically introduce a different negative sign (-) to resolve this conflict.

Aside from that are there any disadvantages of always enabling this behavior?
Comment 6 Tom Dzmelyk 2024-05-28 03:14:00 UTC
(In reply to fanzhuyifan from comment #5)
> The only problem I foresee is a conflict when users start a new calculation
> by pressing/clicking the minus sign. It could either mean use the old result
> and subtract, or the negative sign in starting a new calculation. The
> calculators I have used typically introduce a different negative sign (-) to
> resolve this conflict.
> 
> Aside from that are there any disadvantages of always enabling this behavior?

I would think anyone who is starting a new calculation is going to hit "Clear". Like guimarcalsilva said, this is basically the standard behavior for calculators going back quite a long time. I don't remember how the Windows 3.1 calculator behaved but it definitely did this from Windows 95 onward.  It's still the behavior in the Windows Calculator and still the behavior in the Gnome Calculator. It is definitely the expected behavior.
Comment 7 2724167997 2024-05-28 03:50:28 UTC
(In reply to fanzhuyifan from comment #5)
> The only problem I foresee is a conflict when users start a new calculation
> by pressing/clicking the minus sign. It could either mean use the old result
> and subtract, or the negative sign in starting a new calculation. The
> calculators I have used typically introduce a different negative sign (-) to
> resolve this conflict.
> 
> Aside from that are there any disadvantages of always enabling this behavior?

This means that users have to manually input the previous result as the operand for each new calculation, unless they can directly write out the entire equation in one go, which is rare. Using the previous result as the first operand for the next calculation is the behavior of the vast majority of calculators and was also the previous behavior of KCalc. Everyone is accustomed to this practice. Especially when I use the calculator for long binary calculations or numbers expressed in scientific notation, having to re-enter the result each time is unacceptable.
Comment 8 Kerr Avon 2024-05-28 09:35:42 UTC
I agree with the comments. Please revert back to the previous behaviour or allow it in configuration settings. The input text is also too small for my eyesight and I don't see any setting to change that either. It was perfect before, so not sure why the UX changes were necessary.
Comment 9 Gabriel Barrantes 2024-05-29 00:27:12 UTC
Created attachment 169923 [details]
Proposed behavior

Proposed behavior
Comment 10 Gabriel Barrantes 2024-05-29 00:30:06 UTC
(In reply to Kerr Avon from comment #8)
> I agree with the comments. Please revert back to the previous behaviour or
> allow it in configuration settings. The input text is also too small for my
> eyesight and I don't see any setting to change that either. It was perfect
> before, so not sure why the UX changes were necessary.

check the proposed behavior attachment, is that what you all are looking for?
ps: the font size thing will be fixed eventually...
Comment 11 fanzhuyifan 2024-05-29 02:17:32 UTC
(In reply to Gabriel Barrantes from comment #10)
> (In reply to Kerr Avon from comment #8)
> > I agree with the comments. Please revert back to the previous behaviour or
> > allow it in configuration settings. The input text is also too small for my
> > eyesight and I don't see any setting to change that either. It was perfect
> > before, so not sure why the UX changes were necessary.
> 
> check the proposed behavior attachment, is that what you all are looking for?
> ps: the font size thing will be fixed eventually...

Looks good to me! You could also tag the usability/vdg team in the MR to get their feedback.
Comment 12 James House-Lantto 2024-05-29 10:41:07 UTC
I've never seen a calculator, physical or otherwise, that won't append an operation to the previous one... my calculator watch in the 80's did this.....

A question. If this is now the default behavior, what is the point of the "Clear" vs "All Clear" buttons? 

I got curious, so I checked, I tried about a dozen other calculator apps, Gnome, Qualculate, speedcrunch, etc. The old Texas Instruments in my closet.  

They all work the same way, Kcalc is the only one I can find anywhere that DOESN't append operations.
Comment 13 Tom Dzmelyk 2024-05-29 19:26:57 UTC
(In reply to Gabriel Barrantes from comment #10)
> (In reply to Kerr Avon from comment #8)
> > I agree with the comments. Please revert back to the previous behaviour or
> > allow it in configuration settings. The input text is also too small for my
> > eyesight and I don't see any setting to change that either. It was perfect
> > before, so not sure why the UX changes were necessary.
> 
> check the proposed behavior attachment, is that what you all are looking for?
> ps: the font size thing will be fixed eventually...

This does seem to match the behavior of 24.02.2.  Once there is a patch available I can test it to verify for sure.
Comment 14 Phil Brown 2024-05-29 23:07:38 UTC
Comment on attachment 169923 [details]
Proposed behavior

Gabriel, how does your proposal work with multi digit numbers if it is calculating the answer every time you enter a digit?  It should work like a real calculator, and only calculate the answer when you hit an operator
Comment 15 Antonio Rojas 2024-05-29 23:19:25 UTC
*** Bug 487772 has been marked as a duplicate of this bug. ***
Comment 16 Gabriel Barrantes 2024-05-30 02:29:00 UTC
Created attachment 169965 [details]
demo 2
Comment 17 Phil Brown 2024-05-30 02:30:48 UTC
Comment on attachment 169965 [details]
demo 2

do 20*15/8.5
Comment 18 Phil Brown 2024-05-30 02:35:02 UTC
Comment on attachment 169965 [details]
demo 2

The point of my question was what happens when *all* the operands have multiple digits. Do a demo where they are all 3 digit numbers
Comment 19 Gabriel Barrantes 2024-05-30 02:37:34 UTC
Created attachment 169966 [details]
demo3
Comment 20 Gabriel Barrantes 2024-05-30 02:40:23 UTC
(In reply to Phil Brown from comment #18)
> Comment on attachment 169965 [details]
> demo 2
> 
> The point of my question was what happens when *all* the operands have
> multiple digits. Do a demo where they are all 3 digit numbers

check demo3
Comment 21 Phil Brown 2024-05-30 02:47:29 UTC
Comment on attachment 169966 [details]
demo3

OK, so you have it calculating a result with every keystroke, unlike every other calculator since the invention of the electronic calculator
Comment 22 fanzhuyifan 2024-05-30 02:57:48 UTC
(In reply to Phil Brown from comment #21)
> Comment on attachment 169966 [details]
> demo3
> 
> OK, so you have it calculating a result with every keystroke, unlike every
> other calculator since the invention of the electronic calculator

That was intentionally implemented in https://invent.kde.org/utilities/kcalc/-/merge_requests/84 as a feature. Please keep the discussion here on topic about chaining results into the next calculation, which seems to be fully implemented in the demos.
Comment 23 Phil Brown 2024-05-30 03:02:01 UTC
(In reply to fanzhuyifan from comment #22)
> (In reply to Phil Brown from comment #21)
> > Comment on attachment 169966 [details]
> > demo3
> > 
> > OK, so you have it calculating a result with every keystroke, unlike every
> > other calculator since the invention of the electronic calculator
> 
> That was intentionally implemented in
> https://invent.kde.org/utilities/kcalc/-/merge_requests/84 as a feature.
> Please keep the discussion here on topic about chaining results into the
> next calculation, which seems to be fully implemented in the demos.

the only reason this is broken is because of the faulty design. No other calculator implements this "feature". AFAICT you are the only person who wanted this "feature". All it does is waste CPU cycles.
Comment 24 Metz 2024-06-04 15:23:54 UTC
Oh thanks so much this gets rolled back. This change severly hampered my workflow. Having a calculator not continue using the result is honestly just weird and absolutely non-standard behaviour. Was forced to downgrade to be able to continue working as usual.
Comment 25 Marian 2024-06-04 19:33:30 UTC
I can't believe someone actually changed the behaviour so that it's no longer possible to use the last result for the next calculation. It completely destroys the work flow. Now I have to MS and MR after a calculation to use the result for the next one. Absolutely weird!
I hope this change will be reverted to the standard behaviour.
Comment 26 ezh 2024-06-05 07:36:07 UTC
I requested this feature, this a very useful feature. Sorry I could not test it out. There is no way to beta test the changes... :(

I have an old notebook with Neon Unstable, but I cannot use it as a daily driver, since very often after updates it just do not
work correctly and you have to wait for fixes for weeks...

KDE should really think how to change it. For example, allow to install a program from unstable KDE Wear channel to a stable distribution.
Comment 27 tatami.deviate819 2024-06-05 20:48:15 UTC
(In reply to Kerr Avon from comment #8)
> I agree with the comments. Please revert back to the previous behaviour or
> allow it in configuration settings. The input text is also too small for my
> eyesight and I don't see any setting to change that either. It was perfect
> before, so not sure why the UX changes were necessary.

YES, revert back to automatically continuing the calculation like previous versions. Also, bring back using the DEL key to clear out all data and start from 0 (which does not currently work anymore, as of latest version. I have to click the "AC" button within the app to do what the DEL key used to do in previous versions)

I enjoy the new UX feature of having a line above that keeps all entries, like a phone calc app. But this weird not continuing calculation and DEL key no longer clearing all input, is bizarre choice!
Comment 28 Gabriel Barrantes 2024-06-05 20:50:00 UTC
Created attachment 170185 [details]
Demo 4
Comment 29 Gabriel Barrantes 2024-06-05 20:51:09 UTC
(In reply to Gabriel Barrantes from comment #28)
> Created attachment 170185 [details]
> Demo 4

check demo4, any suggestions?
Comment 30 tatami.deviate819 2024-06-05 20:56:22 UTC
(In reply to tatami.deviate819 from comment #27)
> (In reply to Kerr Avon from comment #8)
> > I agree with the comments. Please revert back to the previous behaviour or
> > allow it in configuration settings. The input text is also too small for my
> > eyesight and I don't see any setting to change that either. It was perfect
> > before, so not sure why the UX changes were necessary.
> 
> YES, revert back to automatically continuing the calculation like previous
> versions. Also, bring back using the DEL key to clear out all data and start
> from 0 (which does not currently work anymore, as of latest version. I have
> to click the "AC" button within the app to do what the DEL key used to do in
> previous versions)
> 
> I enjoy the new UX feature of having a line above that keeps all entries,
> like a phone calc app. But this weird not continuing calculation and DEL key
> no longer clearing all input, is bizarre choice!

CORRECTION: its not even part of this bug so apologies for amending this!! The DEL key DOES do what im used to it doing. But not after the input error happens and shows in app, after trying to continue a calculation. If one is "using the app correctly" than the DEL key still functions "properly"
Comment 31 Bug Janitor Service 2024-06-05 21:01:47 UTC
A possibly relevant merge request was started @ https://invent.kde.org/utilities/kcalc/-/merge_requests/94
Comment 32 SigHunter 2024-06-06 06:55:53 UTC
Thank you very much @gabrielbarrantes!
the patch is for master branch, is there a way to use this patch with 24.05.0?
Comment 33 fanzhuyifan 2024-06-06 14:52:19 UTC
(In reply to tatami.deviate819 from comment #30)
> (In reply to tatami.deviate819 from comment #27)
> > (In reply to Kerr Avon from comment #8)
> > > I agree with the comments. Please revert back to the previous behaviour or
> > > allow it in configuration settings. The input text is also too small for my
> > > eyesight and I don't see any setting to change that either. It was perfect
> > > before, so not sure why the UX changes were necessary.
> > 
> > YES, revert back to automatically continuing the calculation like previous
> > versions. Also, bring back using the DEL key to clear out all data and start
> > from 0 (which does not currently work anymore, as of latest version. I have
> > to click the "AC" button within the app to do what the DEL key used to do in
> > previous versions)
> > 
> > I enjoy the new UX feature of having a line above that keeps all entries,
> > like a phone calc app. But this weird not continuing calculation and DEL key
> > no longer clearing all input, is bizarre choice!
> 
> CORRECTION: its not even part of this bug so apologies for amending this!!
> The DEL key DOES do what im used to it doing. But not after the input error
> happens and shows in app, after trying to continue a calculation. If one is
> "using the app correctly" than the DEL key still functions "properly"

Please open a separate bug report for this, thanks!
Comment 34 Gerd v. Egidy 2024-06-10 20:06:38 UTC
I recently upgraded to 24.05.0 and was also puzzled by the new behavior of not reusing previous results. This is a feature I used very often. Very good that this will be addressed.

But there is another, probably related issue:

I usually have the "Numeral System Mode" activated with the bit editor enabled. I often need to set individual bits, for example from a register datasheet I read that I have to enable bit 7, bit 9, bit 14. Then I click these bits in the bit editor to enable them and get a number shown as decimal or hex in the result display. I then want to be able to use that number as part of a calculation, for example by shifting the bits by a given amount. I want to directly hit the "Lsh" button and continue my calculation. So basically using the bit editor as input method for a calculation.

Will the proposed patch also allow this? On a first glance it looks to me like it currently only works after pressing = and not when bit-editing.
Comment 35 Exanime 2024-06-12 15:36:17 UTC
Affected by this regression... it makes kcalc unusable

I don't mean to sound bitchy but, how did this make it to publishing?!
Comment 36 Exanime 2024-06-12 15:43:39 UTC
(In reply to Gabriel Barrantes from comment #3)
> This was done by design, I am not quite sure what people would prefer tho,
> we could add a config option to set this behavior.

I do not understand the use case this new design is supposed to address but it breaks convention with usability of any calculator I have worked with in the last 30 years.

At the very least, yes an option to return to previous behaviour would work (ideally as a default).
Comment 37 Exanime 2024-06-12 15:55:12 UTC
(In reply to Gabriel Barrantes from comment #29)
> (In reply to Gabriel Barrantes from comment #28)
> > Created attachment 170185 [details]
> > Demo 4
> 
> check demo4, any suggestions?

This would work. I honestly still do not see the point of the "preliminary results before hitting =" Honestly, it seems like those gimmicky features Apple implements. However, if it was requested and people want to keep it, fine. As long as we can carry the result into the next calculation
Comment 38 ihipop 2024-06-13 02:36:22 UTC
Created attachment 170446 [details]
then the switch  of "repeat operation on every result " is not functional

(In reply to Gabriel Barrantes from comment #3)
> This was done by design, I am not quite sure what people would prefer tho,
> we could add a config option to set this behavior.

if this is by design, then the switch  of "repeat operation on every result " is not functional

this is a bug Anyway
Comment 39 fanzhuyifan 2024-06-14 16:19:35 UTC
*** Bug 488483 has been marked as a duplicate of this bug. ***
Comment 40 Gabriel Barrantes 2024-06-18 00:12:01 UTC
Git commit 57dda4e5f858e221abdfac6a777575bb3346649c by Gabriel Barrantes.
Committed on 18/06/2024 at 00:07.
Pushed by gabrielbarrantes into branch 'master'.

Chain result upon equal clicked

Modify behavior to load last calculation result into the input display
when "equal" is clicked, this will also create a new entry in the history
panel. After loading the result this can be used for further calculations.

Also update behavior of "M+", "M-", "MS" and "Dat" to be compatible with
the new changes.

M  +69   -63   kcalc.cpp
M  +5    -2    kcalc.h
M  +34   -0    kcalc_display.cpp
M  +1    -0    kcalc_display.h
M  +57   -0    kcalc_input_display.cpp
M  +5    -0    kcalc_input_display.h
M  +15   -5    kcalc_parser.cpp
M  +8    -2    kcalc_parser.h

https://invent.kde.org/utilities/kcalc/-/commit/57dda4e5f858e221abdfac6a777575bb3346649c
Comment 41 popov895 2024-06-18 08:57:20 UTC
Will this fix appear in 24.05.2?
Comment 42 Antonio Rojas 2024-06-18 13:07:55 UTC
*** Bug 488660 has been marked as a duplicate of this bug. ***
Comment 43 Antonio Rojas 2024-06-19 11:42:43 UTC
*** Bug 488726 has been marked as a duplicate of this bug. ***
Comment 44 Gabriel Barrantes 2024-06-19 19:09:15 UTC
Git commit e11903526a36bb1a85529f9d137257b54e8163fa by Gabriel Barrantes.
Committed on 19/06/2024 at 19:01.
Pushed by gabrielbarrantes into branch 'release/24.05'.

Chain result upon equal clicked

Modify behavior to load last calculation result into the input display
when "equal" is clicked, this will also create a new entry in the history
panel. After loading the result this can be used for further calculations.

Also update behavior of "M+", "M-", "MS" and "Dat" to be compatible with
the new changes.

(cherry picked from commit 57dda4e5f858e221abdfac6a777575bb3346649c)

Co-authored-by: Gabriel Barrantes <gabriel.barrantes.dev@outlook.com>

M  +69   -63   kcalc.cpp
M  +5    -2    kcalc.h
M  +34   -0    kcalc_display.cpp
M  +1    -0    kcalc_display.h
M  +57   -0    kcalc_input_display.cpp
M  +5    -0    kcalc_input_display.h
M  +15   -5    kcalc_parser.cpp
M  +8    -2    kcalc_parser.h

https://invent.kde.org/utilities/kcalc/-/commit/e11903526a36bb1a85529f9d137257b54e8163fa
Comment 45 popov895 2024-06-19 20:02:21 UTC
Thanks!
Comment 46 Exanime 2024-06-20 12:46:26 UTC
Awesome, thanks for your efforts!
Comment 47 Gabriel Barrantes 2024-06-21 03:15:19 UTC
*** Bug 488852 has been marked as a duplicate of this bug. ***
Comment 48 Antonio Rojas 2024-06-27 07:42:24 UTC
*** Bug 489287 has been marked as a duplicate of this bug. ***
Comment 49 Christophe Marin 2024-06-29 06:11:06 UTC
*** Bug 489339 has been marked as a duplicate of this bug. ***
Comment 50 irongrinder 2024-06-29 21:24:53 UTC
I will never understand this chance. Like, if I don't want to use the last output? I clear it.
Comment 51 Antonio Rojas 2024-07-01 11:40:27 UTC
*** Bug 489539 has been marked as a duplicate of this bug. ***
Comment 52 Fonic 2024-07-11 09:56:41 UTC
Thank you for fixing this. The previous change to no longer chain results rendered KCalc almost useless for daily use.

IMHO, there should be better checks in place to catch those kind of goofs BEFORE they get published.
Comment 53 jcfisher 2024-07-19 02:06:35 UTC
I'm not sure if this belongs in this bug report, but a new one, but the fix in 24.5.2 makes the workflow even worse.

Starting a new calculation after a result will now not clear the result if you start a new calculation. Other calculators allow you to either continue the previous calculation by entering in a new operator, or will clear the result if you enter a number.

Expected behviour:
Keystrokes (Result)
1. 9 * 9 [Enter] (9*9=81)
2. /3 [Enter] (81/3=27)
3. 2 + 4 [Enter] (2+4=6)

Current behaviour:
Keystrokes (Result)
1. 9 * 9 [Enter] (9*9=81)
2. /3 [Enter] (81/3=27)
3. 2 + 4 [Enter] (272+4=276)
Comment 54 ihipop 2024-07-19 02:12:26 UTC
https://bugsfiles.kde.org/attachment.cgi?id=170446
it seems that this switch still not works