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

1. 
   ghost commented at 10:22 pm on March 28, 2021: none

   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.

2. Display node address in peer table with monospace font a7c067a4ad
3. hebasto added the label Feature on Mar 28, 2021
4. hebasto added the label Design on Mar 28, 2021
5. 
   hebasto commented at 10:31 pm on March 28, 2021: member

   This approach couldn’t work on macOS, though didn’t test yet.
6. 
   jarolrod commented at 0:13 am on March 29, 2021: member

   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 (https://github.com/bitcoin-core/gui/pull/79).

7. 
   ghost commented at 8:01 am on March 29, 2021: none

   @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).

8. 
   rebroad commented at 10:56 am on March 29, 2021: contributor

   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.

9. 
   hebasto commented at 3:44 pm on March 29, 2021: member

   @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 ?

10. 
    ghost commented at 4:18 pm on March 29, 2021: none

    @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.

11. 
    hebasto commented at 7:52 pm on March 30, 2021: member

    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).

12. 
    DrahtBot commented at 6:30 pm on April 28, 2021: contributor

    🐙 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”.

13. DrahtBot added the label Needs rebase on Apr 28, 2021
14. hebasto removed the label Feature on May 10, 2021
15. 
    luke-jr commented at 6:56 pm on June 12, 2021: member

    Normally network addresses aren’t fixed-length, so weak NACK.
16. 
    shaavan commented at 6:24 pm on July 30, 2021: contributor

    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.

17. hebasto added the label Waiting for author on Sep 7, 2021
18. 
    hebasto commented at 7:26 am on September 13, 2021: member

    Closing due to a long period of inactivity.
19. hebasto closed this on Sep 13, 2021

    ---

20. bitcoin-core locked this on Sep 13, 2022

Contributors
ghost hebasto jarolrod rebroad DrahtBot luke-jr shaavan

Labels
Waiting for author Needs rebase Design