Actually, too many bugs since 24.05.0. It would be great to revert back to the state before 24.05.0, properly refine the work with input and display fields, and then merge it into the stable branch.

(In reply to popov895 from comment #1)
> Actually, too many bugs since 24.05.0. It would be great to revert back to
> the state before 24.05.0, properly refine the work with input and display
> fields, and then merge it into the stable branch.

At this point I honestly feel this should be considered...

A possibly relevant merge request was started @ https://invent.kde.org/utilities/kcalc/-/merge_requests/114

Git commit e137c09ce75737cae0a2f3e86083d425b77bc4f6 by Gabriel Barrantes.
Committed on 05/07/2024 at 03:31.
Pushed by gabrielbarrantes into branch 'master'.

Fix bugs in Numeral system

M  +28   -1    kcalc.cpp
M  +2    -0    kcalc.h

https://invent.kde.org/utilities/kcalc/-/commit/e137c09ce75737cae0a2f3e86083d425b77bc4f6

> II. If the display field contains a number, switching the numeral system
> sometimes doesn't display the result for octal and binary numeral systems.
> Steps to reproduce:
> 
> 1. Open KCalc
> 2. Switch to the Numeral System Mode
> 3. Switch to the decimal numeral system
> 4. Enter 99+1: the display field shows 100, the labels below the switches of
> the numeral system show correct values
> 5. Switch to the hex numeral system: the display field shows 9A (it's okay)
> 6. Switch to the octal or binary numeral system: the display field shows
> nothing (it's not okay)

99+1 is not a valid octal entry, that's why the result is not showing up (if you click = it will indicate "input error"), in the near future I don't think this will get fixed because the only reasonable solution would be to change the "99+1" to "0o143+0o1" in the input display but that's a bigger patch... For now I will consider it "not a bug/feature request".

(In reply to Gabriel Barrantes from comment #5)
> 99+1 is not a valid octal entry, that's why the result is not showing up (if
> you click = it will indicate "input error"), in the near future I don't
> think this will get fixed because the only reasonable solution would be to
> change the "99+1" to "0o143+0o1" in the input display but that's a bigger
> patch... For now I will consider it "not a bug/feature request".

The result of 99+1 is 100, which is displayed in the display field. Therefore, I expect that switching the numeral system will make the display field to show the result of the operation (100 in the above case) in the selected numeral system (9A for hex, 144 for octal and 1100100 for binary). This is exactly how it works now for hex, but not for octal or binary numeral systems.

Ah, now I figure out that switching the numeral system also affects how the expression in the input field is interpreted. Now I'm even more confused as to how it should be.

it leads to issues, for example:

if you are in hex mode and enter 10+1 result is 11 hex (17 decimal)
and then change to binary, what should be done?
I am thinking on these 2 possibilities:
1. interpret the input as binary-> new result = 11 bin (3 decimal)
2. add a 0x to the input, 0x10+0x1 same result but change it to binary, so result = 10001

however if the input is 1A (hex mode)  and then mode is changed to binary:
1. can't be done, so it throws input error since 1A is not a valid entry for the binary mode
2. is a decent choice as I said that would keep the entry valid...

Currently is doing 1 in all cases. 2 is probably better but requires some development in the component...

You are over thinking it. When switching to a different radix the VALUE should be shown in the new radix so if you have 11 decimal you would get 0b hex and 1011 binary and 13 octal. 
Play with galculator it does it right
Previous versions of kcalc were fine, I dont get why all the big changes are happening

(In reply to cat22 from comment #9)
> You are over thinking it. When switching to a different radix the VALUE
> should be shown in the new radix so if you have 11 decimal you would get 0b
> hex and 1011 binary and 13 octal. 
> Play with galculator it does it right
> Previous versions of kcalc were fine, I dont get why all the big changes are
> happening

that's the current implemented behavior.

(In reply to cat22 from comment #9)
> You are over thinking it. When switching to a different radix the VALUE
> should be shown in the new radix so if you have 11 decimal you would get 0b
> hex and 1011 binary and 13 octal. 
> Play with galculator it does it right
> Previous versions of kcalc were fine, I dont get why all the big changes are
> happening

Before 24.05.0, there was only one field to display the result of an expression, but now there are two fields: one to enter an expression and another to display the result of this expression.  Therefore, it's not clear what exactly should happen when you change the radix. IMO it currently works as expected: if I change the radix, then I'm going to enter the expression in that radix. If I just want to see the result of an expression in a different radix, I can see it below the switches of the radix.