
Closes #159.
Nice. Concept ACK
758 | + if (conn_type == "feeler") return "Outbound feeler"; 759 | + if (conn_type == "addr-fetch") return "Outbound address fetch"; 760 | + // Inbound peer connections 761 | + if (conn_type == "inbound") return "Inbound full relay"; 762 | + if (conn_type == "inbound-block-relay") return "Inbound block relay"; 763 | + return "";
nit: Would be nice if this default fallback was replaced with an assert(false) and the above ifs with an enum-switch-case
Agree, but ISTM that only works for integer types.
ConnectionType is an enum class (implementation defined integer)
Right, I wanted to do that but the ConnectionType enum wasn't exposed in CNodeStats. Ok, done.
Concept ACK.
224 | @@ -224,6 +225,9 @@ namespace GUIUtil 225 | /* Convert OS specific boost path to QString through UTF-8 */ 226 | QString boostPathToQString(const fs::path &path); 227 | 228 | + /* Convert ConnectionType enum to QString */
571b0469fa952be98874d1afd772a7fa708dd83f
This comment is not Doxygen-compatible.
thanks! fixed
759 | + case ConnectionType::FEELER: return "Outbound feeler"; 760 | + case ConnectionType::ADDR_FETCH: return "Outbound address fetch"; 761 | + } // no default case, so the compiler can warn about missing cases 762 | + assert(false); 763 | +} 764 | +
571b0469fa952be98874d1afd772a7fa708dd83f
The returned values should be translated.
UX note: I have a personal preference do not capitalize the first letter of returned values. Feel free to ignore it.
I also prefer all lowercase (e.g. rpc/cli) but the GUI UI uses capitalization (I hesitated to use titlecase here).
I perceive it like "Connection type: Outbound full relay". That's why I prefer the lowercased variant.
If the capitalized variant will be required in some other places in the GUI, it is easy to provide it with a generic function.
I'm not a design expert, then I'm fine with any variant.
Thanks--translated and changed to titlecase for coherence with the general GUI UI.
748 | @@ -749,6 +749,19 @@ QString boostPathToQString(const fs::path &path) 749 | return QString::fromStdString(path.string()); 750 | } 751 | 752 | +QString ConnectionTypeToQString(ConnectionType conn_type) 753 | +{ 754 | + switch (conn_type) { 755 | + case ConnectionType::INBOUND: return "Inbound full relay";
571b0469fa952be98874d1afd772a7fa708dd83f
It seems not always true :)
IIUC, you recent changes in bitcoin-cli distinguish "block relay" for inbound connections as well.
IIUC, you recent changes in
bitcoin-clidistinguish "block relay" for inbound connections as well.
Yes, I'm anticipating inbound full relay and inbound block relay connection types (https://github.com/bitcoin/bitcoin/pull/20726 and https://github.com/bitcoin/bitcoin/pull/20729) but I guess it's better to revert to just inbound for now and update it later.
Now "Inbound"
1076 | @@ -1077,14 +1077,17 @@ 1077 | </widget> 1078 | </item> 1079 | <item row="1" column="0"> 1080 | - <widget class="QLabel" name="label_23"> 1081 | + <widget class="QLabel" name="peerConnectionTypeLabel"> 1082 | + <property name="toolTip"> 1083 | + <string>The connection type of this peer.</string> 1084 | + </property>
True. Will improve it with more useful info. Perhaps it should link to more information about the connection types (like we have in the codebase), maybe in a markdown file in /doc.
Maybe I should add more useful info, like in the RPC help (getpeerinfo)
Anyway, please keep it useful and succinct, or else do not add it at all :)
Added info similar to the getpeerinfo help, see updated screenshot in the PR description.
Concept ACK.
I have reviewed the code (bf8135db2a658aed3129ec82e237f8030a8ec7dd), and tested it.
I have reviewed the code (8e7f82a6a84c7b2553f88767dd356f480d1ae4b7), and tested it.
The following patch:
--- a/src/qt/forms/debugwindow.ui
+++ b/src/qt/forms/debugwindow.ui
@@ -1079,7 +1079,7 @@
<item row="1" column="0">
<widget class="QLabel" name="peerConnectionTypeLabel">
<property name="toolTip">
- <string>The type of peer connection: Outbound Full Relay (default), Outbound Block Relay (does not relay transactions or addresses), Inbound (initiated by peer), Outbound Manual (added using RPC addnode or -addnode/-connect config options), Outbound Feeler (short-lived, for testing addresses), or Outbound Address Fetch (short-lived, for soliciting addresses).</string>
+ <string>The type of peer connection: Outbound Full Relay (default), Outbound Block Relay (does not relay transactions or addresses), Inbound (initiated by peer), Outbound Manual (added using RPC %1 or %2/%3 config options), Outbound Feeler (short-lived, for testing addresses), or Outbound Address Fetch (short-lived, for soliciting addresses).</string>
</property>
<property name="text">
<string>Connection Type</string>
--- a/src/qt/rpcconsole.cpp
+++ b/src/qt/rpcconsole.cpp
@@ -496,6 +496,8 @@ RPCConsole::RPCConsole(interfaces::Node& node, const PlatformStyle *_platformSty
clear();
GUIUtil::handleCloseWindowShortcut(this);
+
+ ui->peerConnectionTypeLabel->setToolTip(ui->peerConnectionTypeLabel->toolTip().arg("addnode").arg(QString(nonbreaking_hyphen) + "addnode").arg(QString(nonbreaking_hyphen) + "connect"));
}
RPCConsole::~RPCConsole()

ACK 6cd242c50f4a8d3f3c509937d80962fe58096ead, tested on Linux Mint 20 (x86_64) + Qt 5.12.8.
Looks great:

724 | @@ -725,6 +725,7 @@ class CNodeStats 725 | // Name of the network the peer connected through 726 | std::string m_network; 727 | uint32_t m_mapped_as; 728 | + ConnectionType m_conn_type;
a60f67b2fb0eede205db8cce11ad0e6f42dbc90e
This was suggested here https://github.com/bitcoin/bitcoin/pull/19725#discussion_r473361238 and now makes
m_conn_type_string redundant, doesn't makes sense to keep both TBH. Since m_conn_type_string is only used in getpeerinfo then drop it and refactor ConnectionTypeAsString to take conn_type instead?
Concept ACK, but RPC changes (refactoring) can only be made in the main repo
Done, I think. Should I close this PR and re-open in the main repo?
Maybe just open a pr in the main repo with the first and last commits?
IMO this isn't a RPC change, it's just a member refactor in a net struct, and the refactor is motivated by this GUI change. Otherwise this can go forward in 2 ways I think, either leave this as it was, and then in main repo drop the redundant member, or 1st refactor and make this dependant of that PR.
Opened the same pull in https://github.com/bitcoin/bitcoin/pull/20778 and will let the maintainers decide, closing this one for now to not maintain multiple pulls.
Just noting that redundancy is not a blocker, but could be avoided.
It was suggested to re-open here.
Concept re-ACK. Thanks for re-opening.
Rebased.
Rebased git range-diff ae8f797 aef9693 7098509
248 | @@ -249,7 +249,7 @@ static RPCHelpMan getpeerinfo() 249 | recvPerMsgCmd.pushKV(i.first, i.second); 250 | } 251 | obj.pushKV("bytesrecv_per_msg", recvPerMsgCmd); 252 | - obj.pushKV("connection_type", stats.m_conn_type_string); 253 | + obj.pushKV("connection_type", ConnectionTypeAsString(stats.m_conn_type));
70985097c00827de94a7922620b63e1ee10dd53d
Mind fixing https://github.com/bitcoin/bitcoin/pull/19725/commits/395acfa83a5436790c1a722a5609ac9d48df235f (https://github.com/bitcoin/bitcoin/pull/19725) by aligning the order of the "connection_type" field both in RPC help and in RPC output?
thanks; done
Thanks @hebasto, updated the last commit to move the getpeerinfo connection_type help to the correct place per review feedback in #163 (review) and updated the commit message.
re-ACK be8294ff428da7d13043b3f9a27d7ace1c2dadf4
Concept ACK
Rebased after the merge of https://github.com/bitcoin/bitcoin/pull/20786.
re-ACK 20fa97560b2d27f94f556a570f3556356877b79f, only rebased since my previous review due to the conflict with https://github.com/bitcoin/bitcoin/pull/20786, verified with
$ git range-diff master be8294ff428da7d13043b3f9a27d7ace1c2dadf4 20fa97560b2d27f94f556a570f3556356877b79f
ACK 20fa97560b2d27f94f556a570f3556356877b79f
Tested on macOS Big Sur 11.1 with qt 5.15.2. Looks great! <img width="497" alt="Screen Shot 2021-01-08 at 11 01 46 AM" src="https://user-images.githubusercontent.com/23396902/104039378-4c359b00-51a4-11eb-827e-8b5f75dc2f20.png">
Small NIT: There's a lot of text in the tooltip. It would be nice if all the possible values were put into a list instead of separated by commas. It would look something like this, which to me would be an improvement.
See: Supported HTML Subset,
Better? If yes, bold or no?
Also, any opinions on Inbound being first in the list vs where it is currently.

@jonatack the list looks great! I think not-bold is better. I think that inbound can stay where it is. If i may, I would suggest one more thing:
Write the descriptions like this:
Outbound Block Relay: does not relay transactions or addresses
instead of:
Outbound Block Relay (does not relay transactions or addresses)
- remove RPC and option names from the translatable string
- use non-breaking hyphens
per review feedback
re-ACK 06ba9b300866f33e21512af9d7d2891ee1501bf4, the tooltip content is organized as unordered list.
re-ACK 06ba9b300866f33e21512af9d7d2891ee1501bf4
1076 | @@ -1077,14 +1077,17 @@ 1077 | </widget> 1078 | </item> 1079 | <item row="1" column="0"> 1080 | - <widget class="QLabel" name="label_23"> 1081 | + <widget class="QLabel" name="peerConnectionTypeLabel"> 1082 | + <property name="toolTip"> 1083 | + <string>The type of peer connection:<ul><li>Inbound: initiated by peer</li><li>Outbound Full Relay: default</li><li>Outbound Block Relay: does not relay transactions or addresses</li><li>Outbound Manual: added using RPC %1 or %2/%3 configuration options</li><li>Outbound Feeler: short-lived, for testing addresses</li><li>Outbound Address Fetch: short-lived, for soliciting addresses</li></ul></string>
translation nit: How are translators supposed to translate :<ul><li>? It might be better to say "Can be one of %s" and then use Join(translated_strings, ", ") or simply "Refer to the getpeerinfo RPC help for details on the connection types"?
translation nit: How are translators supposed to translate
:<ul><li>?
There was a discussion in private IRC with @jonatack:
<hebasto> 14:24:52 but I expect the translators' burden :) 14:25:39 hope that translators are aware of escaping :)
I'm not an expert in translation but I believe that :<ul><li> is not a subject to translate as %1 or %2.
It might be better to say "Can be one of %s" and then use
Join(translated_strings, ", ")or simply "Refer to the getpeerinfo RPC help for details on the connection types"?
Either of the suggested variants LGTM.
if we replace the escaped markup with placeholders (as done here for the nonbreaking hyphen), is that still QT Designer-friendly?
I think it is. But, tbh, I'd prefer more succinct @MarcoFalke's suggestions.
Thanks. Helpfulness and readability for users were the reasons for the iterations above and it seems best to not regress on those improvements with referring GUI users to the command line or dropping the readable list layout. I'll propose replacing the escaped markup with placeholders.
Why not a single placeholder for the whole unordered list? We still have a (shorter) tooltip in the form file, and make translators' life easier :)
SGTM too.