Makes the peer list display how much you've uploaded/downloaded from each peer.
Here's a screenshot outdated, current of how it looks. You can now sort to see who are the peers you've uploaded the most too.
I also moved RPCConsole::FormatBytes to guiutil::formatBytes so I could use it in the peerlist
55 | @@ -56,7 +56,10 @@ class PeerTableModel : public QAbstractTableModel 56 | NetNodeId = 0, 57 | Address = 1, 58 | Subversion = 2, 59 | - Ping = 3 60 | + // everything after ping will be right aligned
IMO remove this comment.
183 | + return GUIUtil::formatBytes(rec->nodeStats.nRecvBytes); 184 | } 185 | } else if (role == Qt::TextAlignmentRole) { 186 | - if (index.column() == Ping) 187 | + // everything after ping will be right aligned 188 | + if (index.column() >= Ping)
Explicit is better?
switch (index.column()) {
case Ping:
case Sent:
case Received:
return Qt::AlignRight | Qt::AlignVCenter;
default:
return QVariant();
}
(Remove comment above)
Agreed
Tested (almost) ACK 978835f.
Currently Received is the last column, and the following will make this column the biggest:
https://github.com/bitcoin/bitcoin/blob/6ab0e4cf49549640b903bf5fce0e6035b8116397/src/qt/rpcconsole.cpp#L561
IMO the column Node/Service should be the biggest.
Currently the ping column is largest, But I think User Agent might be a the best choice. Anecdotally, it also has the longest, with the most interesting information on its right hand side (where it would be hidden if the column was too small). Also some nodes like to put messages/easter eggs in their user agent, so if we made it the bigger-by-default column they'd be easier to discover.
Either would be better than ping though
new screenshot (also notice someone with a message in their user agent like I mentioned above)
Concept ACK, this is useful info, though we should avoid adding too many columns here.
@laanwj agreed. I looked through CNodeStats to decide what to add and only sent/received bytes seemed interesting to me.
I could maybe imagine someone wanting "length of time connected to that peer" or "per-peer upload/download speeds", but I think the risk of the table getting too busy is pretty low, and we could always implement a way to select which columns you want a-la task manager or p2p clients like bittorrent do.
(that's actually something I'm interested in doing, but it felt like too big a change for my first go at this)
Tested ACK 6b1891e2c04410ebaa1d6399aab56b6c7495d0ff Agree with not adding to much stuff as column (transferred bytes makes sense also because you can sort).
utACK 6b1891e.
ACK 6b1891e