Display node address in peer table with monospace font for clean alignment

[ghost]

0.21.0 on Debian 10 "Buster"

I think it would be nicer and clearer to the user if addresses that consist of a defined static amount of characters, like Onion addresses (16 characters long in v2 format, 56 characters long in v3 format) are displayed with each same visible length.

To achieve this, this PR changes the font of the peer table's node address column to a monospace font.

In the screenshot of how it is now, it leaves a feeling of uncertainty to me that the onion addresses are not displayed in the same length (for each type v2/v3):

With this PR applied it looks like so, nicely clean aligned:

I took over this approach from src/qt/addresstablemodel.cpp lines 214-221, which as I understand causes in the payment tab the receivers address being displayed in monospace font, unlike the receiver's address label below that, so it seems there was also a demand for a fixed-length display of address.

[hebasto]

This approach couldn't work on macOS, though didn't test yet.

[jarolrod]

The address for the peer will appear really small (edit: i guess its not too small) on macOS because of the os default monospace font

You'd either have to detect #ifdef macOS and omit this from applying (not a good option) or use the now embedded monospace font (#79).

[ghost]

@jarolrod For me your macOS screenshot looks ok, no action needed imo.

use the now embedded monospace font (#79).

Would the solution be, to change
return GUIUtil::fixedPitchFont();
to
return GUIUtil::fixedPitchFont(true);
?
This is how it looks on Debian Buster with the embedded monospace font (fixedPitchFont(true)):

If the embedded font should be used, and maybe that could also solve #131, I think it would be good if there would be a global boolean variable that indicates if embedded monospace font shall be used (not only in the overview tab).

[rebroad]

concept NACK - I find the current font more readable, and no mention of the benefit in changing the font, other than "uncertainty", which I personally don't experience.

I do think it would be nice to be able to add extra columns (as shown in your screenshots), but I think ideally these could be optional, and the selections saved between runs.

[hebasto]

@rebroad

I do think it would be nice to be able to add extra columns (as shown in your screenshots), but I think ideally these could be optional, and the selections saved between runs.

#256 ?

[ghost]

@rebroad the columns "Type" and "Network" are not in 0.21.0, they are in current master branch code, from which the screenshots (other than the very first) are.

Non-macOS users would not use embedded font, so it would look like in my second screenshot. The embedded font is only a question for macOS users. I was just curious how it looks like in Debian, and show it.

[hebasto]

I think it would be good if there would be a global boolean variable that indicates if embedded monospace font shall be used (not only in the overview tab).

... and a gui configure option to allow users choose what they like to use (in Options -> Display tab).

[DrahtBot]

🐙 This pull request conflicts with the target branch and needs rebase.

_{Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".}

[luke-jr]

Normally network addresses aren't fixed-length, so weak NACK.

[shaavan]

Concept 0 on this

Though I am able to understand how op is trying to approach this issue. I don’t think it is an optimal solution. Because the address is a large string of characters. And the size of an individual column is quite small in itself. So for such a small font size. A monospace font decreases the readability of the text by a lot.
Though the current choice of font is not perfect, it is still better than a monospace alternative. I think monospaced font would be good for tabular figures, but not so much for non-tabular figures.

[hebasto]

Closing due to a long period of inactivity.