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
Created attachment 169841 [details] Kcalc 24.02.2
*** Bug 487611 has been marked as a duplicate of this bug. ***
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.
(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.
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?
(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.
(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.
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.
Created attachment 169923 [details] Proposed behavior Proposed behavior
(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...
(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.
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.
(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 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
*** Bug 487772 has been marked as a duplicate of this bug. ***
Created attachment 169965 [details] demo 2
Comment on attachment 169965 [details] demo 2 do 20*15/8.5
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
Created attachment 169966 [details] demo3
(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 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
(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.
(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.
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.
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.
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.
(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!
Created attachment 170185 [details] Demo 4
(In reply to Gabriel Barrantes from comment #28) > Created attachment 170185 [details] > Demo 4 check demo4, any suggestions?
(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"
A possibly relevant merge request was started @ https://invent.kde.org/utilities/kcalc/-/merge_requests/94
Thank you very much @gabrielbarrantes! the patch is for master branch, is there a way to use this patch with 24.05.0?
(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!
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.
Affected by this regression... it makes kcalc unusable I don't mean to sound bitchy but, how did this make it to publishing?!
(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).
(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
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
*** Bug 488483 has been marked as a duplicate of this bug. ***
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
Will this fix appear in 24.05.2?
*** Bug 488660 has been marked as a duplicate of this bug. ***
*** Bug 488726 has been marked as a duplicate of this bug. ***
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
Thanks!
Awesome, thanks for your efforts!
*** Bug 488852 has been marked as a duplicate of this bug. ***
*** Bug 489287 has been marked as a duplicate of this bug. ***
*** Bug 489339 has been marked as a duplicate of this bug. ***
I will never understand this chance. Like, if I don't want to use the last output? I clear it.