Change orderbook text alignment

[ghost]

Fix # 1488

[cipig]

values are right-aligned now, thanks
can you make ADEX not cut them off, so all values have the same number of decimals (whatever that number may be)
you can simply make the column wider, there is plenty of unused space on the left anyway

[ghost]

you can simply make the column wider, there is plenty of unused space on the left anyway

The empty space you're talking about is the one between the Quantity column and Price column right ?
If yes, that's not really true, there is not available space between those two because the quantity values on your screen are too small to fill the column's real width

I'm currently trying other solutions, one might be to reduce font pixel size

[ghost]

I also reduced the number of displayed decimals to 6

[cipig]

The empty space you're talking about is the one between the Quantity column and Price column right ?

I was talking about the space left to orderbook, where the chart would be drawn. That space is huge while we are taking here about couple decimals.
Reducing decimals to 6 is not a good idea, since prices in BTC are very often only 1-10 sats. What makes sense to reduce to 6 is the quantity, but afaik that is already the case.
Isn't there a function in QT to say "show me the values with 12 (or whatever) significant places", like

0.12345678
12.34567890
123.45678901
12345678.9012

[cipig]

in this case it does not even make sense to replace the decimals with ...
replacing 2 decimals with 3 . does not save space :-)

[cipig]

here you see the problem with 6 decimals on price, even on DGB/BTC it does not fit
price of DGB is 0.00000074 BTC: https://coinpaprika.com/coin/dgb-digibyte/
orderbook shows an entry with 0.000001... it's likely something like 0.00000077 or so
and for other coins it should actually be more like 10 decimals, see also #955, but that is another story :-)
here: https://coinpaprika.com/coin/bidr-binanceidr/ ... price is 0.000000001443 BTC... 12 significant digits would actually fit well... but that is not possible in mm2 anyway atm, hope it will be in future, so i can post orders for BIDR/BTC too

[cipig]

i changed decimals for price back to 8 in my repo: cipig@e61c4d5
works fine, eg DGB/BTC

now please just get rid of those ..., so all values have the same amount of decimals

keeping the decimals of Quantity and Total to 6 is totally fine.. can even be reduced to 5 for both... 0.000001 BTC (6 decimals) is 0.05 USD, with 5 it would be 0.50 USD... but for price we need 8 decimals

[cipig]

same orderbook with 5 decimals for Quantity and Total, the ... are gone
cipig@2f5e998

still some cases like this

so we should find a better solution other then using fixed number of decimals (the coins have very different valuations from 50000 USD for BTC to 0.00006 USD for BIDR or whatever
but going with 8, 5, 5 for price, quantity and total is good enough for the beginning

[cipig]

btw, why can't i resize the orderbook? i have a huge screen, but the most important things (orderbook and best orders) are tiny, so i can barely see the values, while the rest of the screen is unused

adding a handful of pixels to that orderbook or make it resize with the rest of the screen would not make it necessary to cut 2 decimals, just to make it readable

[ghost]

I increased the width of the orderbook

Also displayed numbers are now strings instead of numbers: they will show up to 10 significant decimals for the price and 8 for the quantity and total

I also reverted the font size to 12

[Milerius]

I increased the width of the orderbook

Also displayed numbers are now strings instead of numbers: they will show up to 10 significant decimals for the price and 8 for the quantity and total

I also reverted the font size to 12

Could you please use the last version tag of https://github.com/MikeMcl/bignumber.js (v.9.0.2) so we don't rely on last master commit.

[ghost]

As discussed with @cipig in private this work will need more research (API and frontend side) for special cases like particular pairs with numerous digits.

To prevent any overflow issue we replaced the use of numeric types by strings in the orderbook

This PR can be reviewed, research will be continued in #1488: please do not close this isssue if this PR is merged, and rename it if necessary.

[cipig]

LGTM
thanks a lot for the changes and all your efforts