Long stream name can overflow recipient header

[gnprice]

If a stream's name is too long to fit in the recipient header, it can take up the whole row and overflow. Here's what that looks like in a debug build:

In a release build, there isn't the loud striped warning, but it's still an overflow:

In particular there's no room left for the topic, or after #172 for the date.

Just how long the stream name needs to be to trigger this depends, naturally, on the size of the device's screen and on the font size. A user who has their system font size set to very large for readability may encounter this at a fairly ordinary length of stream name. It'll also become easier to trigger after #172, with the date occupying part of the width.

Even when things fall short of outright overflow, we'll currently show a long stream name in full even if that leaves very little room at all for the topic:

(The details of how this looks will change when we refresh the message list to the 2023 redesign, #157. But I think the basic layout challenge here will be unchanged.)

So we should adjust this behavior. I think what we ideally want is something like:

• When both stream and topic name are long, they each get a fixed fraction of the available width — perhaps 50/50, or perhaps something like 40/60 to give somewhat more space to the topic.

  (Where "available" means what's left after the fixed widths that go to the date, or to padding, etc.)

• When there's room to fit both in full, though, we show them both in full, even if that means one of them takes 90% of the available width.

  • Moreover the container for the stream name doesn't take up any slack — the topic always appears right after the text of the stream name.

• In between, something reasonable happens. For example if one wants 90% of the available width and the other wants 20%, probably the latter gets all 20% that it wants and the other gets the other 80%.

In CSS I think this could be expressed with a fairly straightforward use of flexbox, and in particular the distinction between flex-grow (which would be nonzero only on the topic) and flex-shrink (which would be positive on both topic and stream name).

I'm not sure offhand how to express it in Flutter. Hopefully it can be done by using the basic Row widget, and its friends like Expanded and Flexible, in the right way. If not, it's always possible to do it with our own render object; but before reaching for that, I'd want to look around to see if someone in the community has produced a good implementation of a port of CSS flexbox, and consider using that instead.

[fizy069]

Not an exact implementation of the behaviour you mentioned in your comment above, but I've solved the overflow issues and ensured that TextOverflow.ellipsis works. For now, I've given fixed values to the size of streamName/topic in case an overflow occurs, else it takes up the entire space.

How does this look?