| Summary: | [Feature] Update input when changing bases | ||
|---|---|---|---|
| Product: | [Applications] kcalc | Reporter: | David Harty <kde> |
| Component: | general | Assignee: | Gabriel Barrantes <gabriel.barrantes.dev> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | benny, ekigwana, gabriel.barrantes.dev, net147, xypron.glpk |
| Priority: | NOR | ||
| Version First Reported In: | 24.05.2 | ||
| Target Milestone: | --- | ||
| Platform: | Manjaro | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | Conversion from Hex to Decimal | ||
|
Description
David Harty
2024-08-23 19:34:08 UTC
Try the latest version (24.08), the new numeral system view allows copying the values. This is something that might get fix at some point (not even Qalculate does it) but changing bases is not currently updating the input display, you can just type 0xfa+120 (in decimal mode). *** Bug 493019 has been marked as a duplicate of this bug. *** This has been working my nerves for a bit now. I imagine this simply needs an input state tracker. E.g. When one enters DEC 16 the tracker stores DEC. When one changes base to HEX, the input is updated by converting DEC 16 to HEX 10 and the state tracker then gets changed to HEX. At the moment the action above converts DEC 16 to HEX 16 which does not make any sense since DEC 16 != HEX 16. HEX 9 to OCT waits for a request for results before complaining about a syntax error. It seems we need an input regex for each mode as well so that invalid input is also not possible. (In reply to Edward Kigwana from comment #3) > This has been working my nerves for a bit now. I imagine this simply needs > an input state tracker. > E.g. > > When one enters DEC 16 the tracker stores DEC. > When one changes base to HEX, the input is updated by converting DEC 16 to > HEX 10 and the state tracker then gets changed to HEX. > > At the moment the action above converts DEC 16 to HEX 16 which does not make > any sense since DEC 16 != HEX 16. HEX 9 to OCT waits for a request for > results before complaining about a syntax error. > > It seems we need an input regex for each mode as well so that invalid input > is also not possible. is not that simple because inputs can be many things now, not a single number that can be easily converted. To convert 10+20+30 for example all the numbers will need to be found and then converted and replaced in the string. Not even Qalculate is doing it... (In reply to Gabriel Barrantes from comment #4) > (In reply to Edward Kigwana from comment #3) > > This has been working my nerves for a bit now. I imagine this simply needs > > an input state tracker. > > E.g. > > > > When one enters DEC 16 the tracker stores DEC. > > When one changes base to HEX, the input is updated by converting DEC 16 to > > HEX 10 and the state tracker then gets changed to HEX. > > > > At the moment the action above converts DEC 16 to HEX 16 which does not make > > any sense since DEC 16 != HEX 16. HEX 9 to OCT waits for a request for > > results before complaining about a syntax error. > > > > It seems we need an input regex for each mode as well so that invalid input > > is also not possible. > > is not that simple because inputs can be many things now, not a single > number that can be easily converted. > To convert 10+20+30 for example all the numbers will need to be found and > then converted and replaced in the string. Not even Qalculate is doing it... I agree it is not simple and only discussed the simple case as an illustrative case. If the input is restricted to one base then it is a matter of using a regex to capture the values and tokens. For the case of the current input it should then be straight forward to do the conversion and leave history alone especially since the history results indicate base. (In reply to Edward Kigwana from comment #5) > (In reply to Gabriel Barrantes from comment #4) > > (In reply to Edward Kigwana from comment #3) > > > This has been working my nerves for a bit now. I imagine this simply needs > > > an input state tracker. > > > E.g. > > > > > > When one enters DEC 16 the tracker stores DEC. > > > When one changes base to HEX, the input is updated by converting DEC 16 to > > > HEX 10 and the state tracker then gets changed to HEX. > > > > > > At the moment the action above converts DEC 16 to HEX 16 which does not make > > > any sense since DEC 16 != HEX 16. HEX 9 to OCT waits for a request for > > > results before complaining about a syntax error. > > > > > > It seems we need an input regex for each mode as well so that invalid input > > > is also not possible. > > > > is not that simple because inputs can be many things now, not a single > > number that can be easily converted. > > To convert 10+20+30 for example all the numbers will need to be found and > > then converted and replaced in the string. Not even Qalculate is doing it... > > I agree it is not simple and only discussed the simple case as an > illustrative case. If the input is restricted to one base then it is a > matter of using a regex to capture the values and tokens. For the case of > the current input it should then be straight forward to do the conversion > and leave history alone especially since the history results indicate base. I might do it at some point, but you can enter prefixes 0x, 0o and 0b, and the numeral system view shows the result for all the other bases. *** Bug 497112 has been marked as a duplicate of this bug. *** (In reply to Gabriel Barrantes from comment #6) >> numeral system view shows the result for all the other bases This is of limited value as these values cannot be copied. (In reply to Heinrich Schuchardt from comment #8) > (In reply to Gabriel Barrantes from comment #6) > > >> numeral system view shows the result for all the other bases > > This is of limited value as these values cannot be copied. They can, right click on them |