| Summary: | hexidecimal notation (instead of decimal) would be useful in some cases | ||
|---|---|---|---|
| Product: | [Applications] kst | Reporter: | Matthew Truch <matt> |
| Component: | ui | Assignee: | kst |
| Status: | RESOLVED INTENTIONAL | ||
| Severity: | wishlist | ||
| Priority: | VLO | ||
| Version: | 1.x | ||
| Target Milestone: | --- | ||
| Platform: | RedHat Enterprise Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
|
Description
Matthew Truch
2004-09-10 21:41:29 UTC
What would happen with non-integer values? Display something like AB.BDEF? Binary values would not seem like a good idea as the labels will become very large very quickly. > What would happen with non-integer values? Display something like AB.BDEF?
>
> Binary values would not seem like a good idea as the labels will become very large very quickly.
I did not think about non-integer values, as to me, hex mode only makes
sense for integers. It's less important to me at this point, however,
since bitwise & and | have been added.
We could assert that hex or binary notation requests only be honored if the axis numbers are integers (typ. range is larger than ~5). I think that the feature really would be useful in many cases. I orignally suggested this to Matt. At the time I was trying to extract, I think, a two bit number from a bitfield timestream using my head (which can subtract powers of two better in hexidecimal than in decimal). If there are now bitwise operators, that solves my problem just as well. (Though, for the record, hexadecimal non-integer numbers are cool...) Hexadecimal non-integer numbers are too uncommon to justify this feature. The needs of the original submitter have been met by other means. |