-
Notifications
You must be signed in to change notification settings - Fork 269
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
Add "Direction" column to peers tab #289
Conversation
There was a problem hiding this 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.
d508c3f
to
8c580ef
Compare
@jarolrod Thanks for reviewing! I added the arrows yesterday but then removed them today, because the |
@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. |
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 |
The current space-ampersand-space, or comma-space, seem like good separators. |
8c580ef
to
d04ebda
Compare
Update: after adding the arrows yesterday, I removed them today because the |
There was a problem hiding this 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.
d04ebda
to
cee6761
Compare
@@ -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{": "}; |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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 %
.
There was a problem hiding this comment.
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..
There was a problem hiding this comment.
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.
cee6761
to
181065c
Compare
181065c
to
2bf3f5a
Compare
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")); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.)
How do you have 3 Block Relay connections in this screenshot? Isn't MAX 2? |
There was a problem hiding this 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.
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. |
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? |
Up for grabs. |
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. |
@prayank23
You're also welcome to join the |
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. |
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
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
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 connectionDirection
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 theDirection/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 theDirection/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.