Description
As mentioned in #372, the "Type" column without the "Direction" one looks indeed like unfinished business.
Personally, I'm using the "Type" column sorting every time I open the GUI. And I'll be very disappointed if we end up with reverting this feature back (see #372).
One of the flaws in the current state is mixing of independent data in the "Address" column content. It leads to unwanted issues (see #397, #400).
Currently, we have two alternative PRs that add the "Direction" column: #317 and #363.
#317 (#289)
- has support of 5 developers (including pr authors)
- 2 developers expressed their satisfaction with the current state (one of these opinions includes a suggestion for a different approach)
- 1 developer submitted an alternative PR
#363
- has support of 1 developer (pr author only)
- 2 developers expressed their disagreement
Nevertheless, I still believe we could find the common ground and reach the rough consensus in this problem.
Here is my attempt at formulating the distinguished issues related to the problem.
Issue 1: Mixing of independent data
The fact is that a connection direction and a peer address are completely independent data, therefore, a table that presents such data to users shouldn't mix them into one column, as this definitely hurts UX.
For historical notes, see:
- Remote peer debug window: Show connection direction (in/out) bitcoin/bitcoin#13483
- GUI: Peer table: Visualize inbound/outbound state for every row bitcoin/bitcoin#13537
Issue 2: Semantics of "arrows"
The fact is that arrow symbols—neither "up" and "down" (current state), nor "left" and "right"—have no implicit or ubiquitous semantics of "inbound" and "outbound". They mean nothing without a context.
Issue 3: Horizontal space and Localization
One of the concerns about adding a new "Direction" column is that it consumes more horizontal space then a symbol does.
As an alternative, the "in" and "out" short words were suggested (disregarding letter capitalization).
The main flaw of such an approach is that the shortest translated words with the suitable meanings could be much longer. It makes this approach practically useless.
Note about symbols
We could replace arrows with symbols with suitable semantics, for example:
- https://github.com/bitcoin-core/gui/blob/master/src/qt/res/icons/tx_input.png
- https://github.com/bitcoin-core/gui/blob/master/src/qt/res/icons/tx_output.png
Or we could choose any other free icons with appropriate semantics.
Note about data mixing
After replacing the meaningless "arrow" symbols with some meaningful ones, it'll still require to move it out from the "Address" column:
- (A) into a new dedicated "Direction" column
- (B) into the current "Type" column
Note about horizontal space and Localization
Unfortunately, the (A) solution won't save the horizontal space in all cases. The "Direction" column still require a header title, e.g., the word "Direction". And, again, its localized variant could be much longer.
Suggested trade-off approach: a combined "Direction/Type" column instead of the current "Type" one
The combining a direction and a type data into one column looks pretty legitimate because these data are closely entangled (see #203).
Here are possible implementations:
- (B.1) an icon-prefixed string
- (B.2) considering that in the current "Type" column cells are empty iif a connection is inbound, we could use the "Inbound" word as a type of inbound connection, and connections with other types are implicitly outbound. In that case no icons/symbols are required at all.
I think the B.2 solution is a good trade-off. And it does not increase the horizontal space usage. Actually, this solution decreases it by removing arrow symbols from the "Address" column.
Searching for productive discussion without opinions based on personal taste.