[Feature] Collapsible/Expandable sequence of small events

[tyreseluo]

PR content

By default, a series of two or more adjacent small events should be collapsed into an abbreviated view that takes up much less vertical space. This will make it easier for the user to focus on important content like text and image messages from other users, rather than less important metadata.

Related PR

• Collapsible/expandable sequence of small events #118

[tyreseluo]

It has been optimized to the summarize function, but I still don't think it's a good way to introduce too much code, but it's currently a huge improvement in performance, and UI rendering over the previous code.

[tyreseluo]

Note: change label to waitting on review.

[kevinaboos]

I appreciate your attempt at this, but unfortunately the fundamental approach here just cannot work.

We can't possibly iterate over the entire timeline multiple times (with lots of huge allocations) in order to pre-calculate a conversion between the regular timeline indexes and the "grouped" indexes. That is just unbelievably inefficient -- imagine if the timeline had millions of items in it. Not to mention, it's even worse because you're doing it on every draw routine.

The good news is that you don't have to do that at all! You can make this algorithm much, much simpler, without the need to pre-determine the set of grouped indexes.

All you have to do is maintain a range of indexes that are grouped together, and as you iterate over each timeline item, you will determine whether each next item you encounter is a candidate to be combined into that group or not. If it is able to be made part of the group (e.g., it is a smallstateevent-like item), then you extend that range to include that item's index, and draw that item as part of the group. If it cannot be part of that group (e.g., it's a message), then the group ends there, and that item will be drawn as an individual regular timeline.

The overall idea is that you never want to look at more items in the timeline than you absolutely have to. We should only ever look at the items/indexes that the PortalList asks for (via next_visible_item()`).

---

In addition, when you're redesigning this, please move as much of the DSL components and Rust code into a separate module. The RoomScreen is already too big.

[tyreseluo]

oh, yes, thanks. good idea to do this.