Blanks instead:

Concept ACK, this seems very useful. I think either the current " & " or a ", " separator would be good. Will test.

I experimented with different ways to try to control where it breaks. I will take another look.

@RandyMcMillan you have two tested ACKs here and it's a nice compact self-contained diff that adds value, so if you find something for that I think you could propose it separately.

Concept ACK.

@RandyMcMillan

Thanks for working on this! It has been in my TODO list for a long time :)

What if to add another tiny change:

--- a/src/qt/guiutil.cpp
+++ b/src/qt/guiutil.cpp
@@ -708,7 +708,7 @@ QString formatServicesStr(quint64 mask)
     }
 
     if (strList.size())
-        return strList.join(" & ");
+        return strList.join("\n");
     else
         return QObject::tr("None");
 }

?

We could get:

Btw, @jonatack's alternative suggestions

Here or in a follow-up, it may be a good idea to use either a non-breaking space before the ampersand or a comma-space to avoid the separator splitting to a line by itself.

also could be implemented in the same line :)

@RandyMcMillan For nice commit history do you mind changing the prefix in the commit message s/peers-tab:/qt:/ ?

See: https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#creating-the-pull-request

Now it will always use multiple lines even when there is enough horizontal space to only use one?

Now it will always use multiple lines even when there is enough horizontal space to only use one?

Right. Is it bad?

Right. Is it bad?

It just trades one dimension for the other. The flexibility of optimizing the available space was what appealed to me.

The flexibility of optimizing the available space was what appealed to me.

You're right, and I agree with you, ceteris paribus. But in this case no other row requires wider space. Therefore, making the column wider is not an optimal way to use the available area.

If the user prefers a wider space to a higher one, the flexible version allows the user to do it with no downside.

Edit: I'd suggest the comma-space separator as it requires fewer characters and is a well-understood separator.

Great suggestion with using "\n" - it eliminates the issue. :)

It only adds vertical size to reduce the horizontal size, I don't see why it's better than the flexibility of the original version to allow the user to optimize the space. :shrugging:

If the user prefers a wider space to a higher one, the flexible version allows the user to do it with no downside.

Edit: I'd suggest the comma-space separator as it requires fewer characters and is a well-understood separator.

The downside of such approach is that some services, that are not placed in the beginning of the line, could just miss user's attention. Of course, it's a minor one.

I lean toward a UI that avoids horizontal scroll bars.
It becomes a usability issue because the horz scroll bar over lays textual information
that a person may try to copy and paste. (This is an issue with the table view itself that I was planning on addressing soon)

I agree with @jonatack, flexible approach would be better IMO, i.e. without "forced" newlines.

I agree with @jonatack and @Talkless
I just wanted to provide examples to prompt discussion on these nuanced decisions. :)

fb5e880 -- looking at the diff lines count I see +7/-3. If drop unrelated changes, it could be +4/-1.

tACK a0f7978 on same environment as previously.