Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add "Direction" column to peers tab #289

Closed

Conversation

jonatack
Copy link
Member

@jonatack jonatack commented Apr 23, 2021

Screenshot from 2021-04-24 13-15-54

This was initially proposed in #179 and saw an enthusiastic reception with several ACKs. One contributor was a weak NACK due to the horizontal space and so this was temporarily dropped, but since then #202 (and soon #256 and #293) resolve the issue. Moreover, the current state of displaying only a connection Type column without a connection Direction column is confusing (e.g. bitcoin/bitcoin#21747 (comment)), particularly as both the direction and the type are displayed in the peer details area with the Direction/Type row.

This patch fixes it and completes the initial proposal in #179 by adding a Direction column, making the peers tab the same as the Direction/Type row in the peer details and the direction and type columns in our other user-facing peer connections table in -netinfo.

Users can now sort the peers table by direction. The default sort is set to inbound, then outbound.

This patch also makes the direction and type translations the same for the 3 places where they are used (the peers column, the peer details row, and its tooltip), adds translator comments to link them together, and adds QStringBuilder fast QString concatenation with the % operator.

Copy link
Member

@jarolrod jarolrod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

I think this is an improvement over the current little arrows next to the address. But, this improvement is dependent on getting translations done.

What if we kept the arrow next to the Inbound and Outbound text. That way, if there is no translation available, the arrows provide some context to go on.

src/qt/peertablemodel.cpp Outdated Show resolved Hide resolved
@jonatack jonatack force-pushed the add-direction-column-to-peers-tab branch from d508c3f to 8c580ef Compare April 24, 2021 11:41
@jonatack
Copy link
Member Author

jonatack commented Apr 24, 2021

What if we kept the arrow next to the Inbound and Outbound text. That way, if there is no translation available, the arrows provide some context to go on.

@jarolrod Thanks for reviewing! I added the arrows yesterday but then removed them today, because the Direction and Type columns should display the same thing as the Direction/Type details row. I also made the direction and type translations the same for the three places where they are used (peers column, peer details row, and its tooltip) and added translator comments.

@RandyMcMillan
Copy link
Contributor

@jonatack - In this previous PR #135 I did something similar...

The goal was to actually embed unicode arrows in the column and not use text for direction at all.

This may be better visually and save column space.

The column sorting function should sort by unicode value with little to no additional work.

I just wanted to mention that since this PR is focusing on the direction column.

@jonatack
Copy link
Member Author

Thanks -- yes, I know but don't prefer a column with just arrows.

More objectively, there is an issue described in the PR description above: the Inbound/Outbound direction is displayed in the peer details area (the Direction/Type row) but not in the peers windows itself, which is confusing to users. Now that space is less of an issue thanks to #202 and #256, we can complete what was started in #179 and properly display the Direction and the Type next to each other as we are already doing in the peer details.

@RandyMcMillan
Copy link
Contributor

#293 should fit with #202 #256 & #179 as well...

What do you think leave the Ampersands or take them out?

@jonatack
Copy link
Member Author

What do you think leave the Ampersands or take them out?

The current space-ampersand-space, or comma-space, seem like good separators.

@jonatack jonatack force-pushed the add-direction-column-to-peers-tab branch from 8c580ef to d04ebda Compare April 25, 2021 13:43
@jonatack
Copy link
Member Author

Update: after adding the arrows yesterday, I removed them today because the Direction and Type columns should display the same thing as the Direction/Type details row. In a new second commit, I made the direction and type translations the same for the three places where they are used (peers column, peer details row, and its tooltip) and added translator comments to link them together. It's not clear to me, however, if the translator comments should refer to places in the codebase or to where the translations are displayed to users.

Copy link

@Talkless Talkless left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tACK d04ebda, tested on Debian Sid with Qt 5.15.2.

src/qt/rpcconsole.cpp Outdated Show resolved Hide resolved
@jonatack jonatack force-pushed the add-direction-column-to-peers-tab branch from d04ebda to cee6761 Compare April 25, 2021 15:38
@hebasto hebasto added the Design label Apr 25, 2021
src/qt/addressbookpage.cpp Show resolved Hide resolved
@@ -52,6 +54,9 @@ const int INITIAL_TRAFFIC_GRAPH_MINS = 30;
const QSize FONT_RANGE(4, 40);
const char fontSizeSettingsKey[] = "consoleFontSize";

const QLatin1String COLON_SPACE{": "};

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting idea. It actually could be constexpr.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was the first thing I tried but the compiler doesn't like it.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's strange, QLatin1String's constructors are constexpr-marked since at least 5.3: https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qstring.h?h=5.3#n89

Sure that wasn't type or something? What kind of message was that? And what compiler?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seemed relevant: https://stackoverflow.com/questions/56201976/qt-vs-constexpr-string-literal

Clang 9 and GCC 10.2.1:

  CXX      qt/libbitcoinqt_a-rpcconsole.o
qt/rpcconsole.cpp:58:32: error: constexpr variable 'COLON_SPACE' must be initialized by a constant expression
static constexpr QLatin1String COLON_SPACE{": "};
                               ^~~~~~~~~~~~~~~~~
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:91:93: note: non-constexpr function 'strlen' cannot be used in a constant expression
    Q_DECL_CONSTEXPR inline explicit QLatin1String(const char *s) noexcept : m_size(s ? int(strlen(s)) : 0), m_data(s) {}
                                                                                            ^
qt/rpcconsole.cpp:58:32: note: in call to 'QLatin1String(&": "[0])'
static constexpr QLatin1String COLON_SPACE{": "};
                               ^
qt/rpcconsole.cpp:59:32: error: constexpr variable 'SPACE' must be initialized by a constant expression
static constexpr QLatin1String SPACE{" "};
                               ^~~~~~~~~~
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:91:93: note: non-constexpr function 'strlen' cannot be used in a constant expression
    Q_DECL_CONSTEXPR inline explicit QLatin1String(const char *s) noexcept : m_size(s ? int(strlen(s)) : 0), m_data(s) {}
                                                                                            ^
qt/rpcconsole.cpp:59:32: note: in call to 'QLatin1String(&" "[0])'
static constexpr QLatin1String SPACE{" "};
                               ^
2 errors generated.

#include <QMenu>
#include <QMessageBox>
#include <QScreen>
#include <QScrollBar>
#include <QSettings>
#include <QString>
#include <QStringBuilder>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if it helps only by including (without using operator %), unless whole bitcoin-qt would be built with QT_USE_QSTRINGBUILDER.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added because this file already uses %.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, QLatin1String and QStringBuilder included because where simply missing, not because of new usage. New usage would be nice though, but I don't want to be too-QString-nazi..

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the nudge, @Talkless. Looked up https://wiki.qt.io/Using_QString_Effectively and updated. Please let me know what you think.

@jonatack jonatack force-pushed the add-direction-column-to-peers-tab branch from cee6761 to 181065c Compare April 28, 2021 19:19
@jonatack
Copy link
Member Author

Rebased due to the merge of #18. Thanks for the reviews @Talkless!

@jonatack jonatack force-pushed the add-direction-column-to-peers-tab branch from 181065c to 2bf3f5a Compare April 28, 2021 23:28
@ghost
Copy link

ghost commented Apr 30, 2021

Concept ACK

return QString::fromStdString(rec->nodeStats.addrName);
case Direction:
//: Connection direction. Also used in ConnectionTypeToQString() and CONNECTION_TYPE_DOC.
return QString(rec->nodeStats.fInbound ? tr("Inbound") : tr("Outbound"));
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we use IN and OUT in caps instead of Inbound and Outbound?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here is how that would look, not a bad idea. But, a) I think this change is ok as is b) would like to hear other opinions.

Screen Shot 2021-04-30 at 3 09 34 AM

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The goal is to unify the peers tab Direction and Type columns with the Direction/Type row in the peer details sidebar, so if the side bar displays "Outbound Full Relay", the main table also displays "Outbound Full Relay" with the ability to sort by either Direction or Type.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I also tried "In/Out" while working on this PR, and the horizontal space isn't reduced unless the column header is "Dir" instead of "Direction". But the other headers are full words.)

@ghost
Copy link

ghost commented Apr 30, 2021

Screenshot from 2021-04-24 13-15-54

How do you have 3 Block Relay connections in this screenshot? Isn't MAX 2?

Copy link
Member

@jarolrod jarolrod left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ACK 2bf3f5a

This patch works well and is a UX improvement. Tested on macOS 11.3 Qt 5.15.2

Thanks for working on this and adding in translator comments.

Screen Shot 2021-04-30 at 2 59 31 AM

@jonatack
Copy link
Member Author

How do you have 3 Block Relay connections in this screenshot? Isn't MAX 2?

We very often have a short-lived third extra block relay connection since the merge of bitcoin/bitcoin#19858.

See this open PR that updates our docs about this: https://github.com/bitcoin/bitcoin/pull/21709/files.

@hebasto
Copy link
Member

hebasto commented Apr 30, 2021

Concept ACK on removing direction info from the "Address" column.

@luke-jr wrt your comment #179 (comment) and new circumstances, did you change your mind?

@jonatack
Copy link
Member Author

Up for grabs.

@jonatack jonatack closed this Apr 30, 2021
@jonatack jonatack deleted the add-direction-column-to-peers-tab branch April 30, 2021 23:31
@ghost
Copy link

ghost commented May 2, 2021

I can work on this. But I am not sure why is this closed and "Up for grabs" because @jonatack already made changes required and reviews looked positive as well.

@hebasto
Copy link
Member

hebasto commented May 2, 2021

@prayank23

I can work on this.

You're also welcome to join the ##bitcoin-core-gui (with two #) channel on IRC :)

@jonatack
Copy link
Member Author

jonatack commented May 2, 2021

Hi @prayank23, sorry for the confusion. I opened this to finish what was started with #179 but decided to not spend further time on GUI/design/QT/UI/translation things. Everything takes time to do well, and discussing each word, arrow, indentation, translation, and consistency question and explanation until everyone is happy is completely normal, but it takes bandwidth in an area that isn't my focus. Cheers.

@jarolrod
Copy link
Member

@hebasto this is no longer up for grabs as it was picked up in #317

@hebasto hebasto added UI All about "look and feel" UX All about "how to get things done" and removed Design Up for grabs UI All about "look and feel" labels May 26, 2021
hebasto added a commit that referenced this pull request Aug 11, 2021
6971e79 gui: add Direction column to peers tab (Jon Atack)

Pull request description:

  Picking up #289

  This adds a `Direction column`, making the peers tab the same as the `Direction/Type` row in the peer details and the direction and type columns in our other user-facing peer connections table in `-netinfo`.

  Users can now sort the peers table by direction. The default sort is set to inbound, then outbound.

  | Master        | PR               |
  | ----------- | ----------- |
  | ![Screen Shot 2021-05-05 at 3 51 09 AM](https://user-images.githubusercontent.com/23396902/117111864-38ff9a00-ad56-11eb-889d-f1c838c845e6.png) | ![Screen Shot 2021-05-05 at 3 35 40 AM](https://user-images.githubusercontent.com/23396902/117111892-4157d500-ad56-11eb-82b1-5bd3e88a4cff.png) |

ACKs for top commit:
  jonatack:
    Tested ACK 6971e79
  ShaMan239:
    tACK 6971e79
  hebasto:
    ACK 6971e79, tested on Linux Mint 20.2 (Qt 5.12.8).

Tree-SHA512: 9716cdedd435f88245a097fed6d4b2b486104d0dd09df739bdb4f2bfad709cbd9c9a231168cc3326e94fa5fddc77dd68f992f20417d04d94930db9fccdbb7de1
hebasto added a commit that referenced this pull request Sep 29, 2021
4832737 qt: connection type translator comments (Jarol Rodriguez)

Pull request description:

  This PR introduces Qt translator comments for `Connection Type` strings in `guiutil.cpp` as well as `rpcconsole.cpp`.

  This is an alternate implementation of the idea presented in the last three commits of #289. It is especially inspired by commit 842f4e8.

  Per [Qt Dev Notes](https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Developer-Notes-for-Qt-Code), it is better to not break up strings when not necessary. This way we preserve the full context for translators.

ACKs for top commit:
  jonatack:
    Code review re-ACK 4832737 per `git diff 371e2b9 4832737`, changes are translator comment edits since my review yesterday (thank you for updating)
  hebasto:
    ACK 4832737

Tree-SHA512: 67e1741e10a2e30cde6d50d3293eec89f0b7641b34463865dc6909d2926cdcf33a7d8c1dc8055d2f85906ad2002cdaa594d37b184d16e2f06614b6c5ad00c982
@bitcoin-core bitcoin-core locked as resolved and limited conversation to collaborators Aug 16, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
UX All about "how to get things done"
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants