Create SuperChatBubble widget. (Resolves #2804)

[angelosilvestre]

Create SuperChatBubble widget. (Resolves #2804)

This PR introduces a SuperChatBubble, which is a copy of SuperReader without scrolling. The subtree is basically the same, with the following differences:

• An IntrinsicWidth was added to make the widget size itself based on its intrinsic width.
• An SuperEditorDryLayout was added to make the IntrinsicWidth use possible.
• The DocumentScaffold was removed from the subtree, because this widget adds the scrolling behavior to the widget. Instead of DocumentScaffold we use ContentLayers and SingleColumnDocumentLayout directly.

I had to keep an AutoScrollController and a ScrollController in the state class because the inner widgets require them.

There are some properties that I'm not sure we need for this widget, like autoFocus, which I think we probably don't want, and keyboardActions.

This PR also modifies the Slack clone to use the new SuperChatBubble widget.

The following screenshot shows SuperChatBubble sized according its intrinsic width.

[matthew-carroll]

• An IntrinsicWidth was added to make the widget size itself based on its intrinsic width.
• An SuperEditorDryLayout was added to make the IntrinsicWidth use possible.

Why are these needed? Is it because of the document layout widget? I would expect us to be able to achieve our goals without extra stuff like this.

I had to keep an AutoScrollController and a ScrollController in the state class because the inner widgets require them.

Then we should change this widgets. Maybe we want named constructors or something, but we shouldn't be creating and passing things that don't have any relevance to the use-case.

There are some properties that I'm not sure we need for this widget, like autoFocus, which I think we probably don't want, and keyboardActions.

For autoFocus, it's probably true we can get rid of that. But we still want content to be selectable and copy-able - does that not require keyboardActions?

[angelosilvestre]

Why are these needed? Is it because of the document layout widget? I would expect us to be able to achieve our goals without extra stuff like this.

We need SuperEditorDryLayout because SuperEditor uses slivers. This widget finds the inner RenderBox, otherwise it needs to be mannually placed inside a CustomScrollview (SuperEditorDryLayout itself is a CustomScrollview).

Without IntrinsicWidth, the document layout seems to take space than it need horizontally.

[matthew-carroll]

We need SuperEditorDryLayout because SuperEditor uses slivers

But this widget doesn't want any scrolling at all. So why don't we build a widget that doesn't use/include slivers?

[angelosilvestre]

But this widget doesn't want any scrolling at all. So why don't we build a widget that doesn't use/include slivers?

@matthew-carroll ContentLayers itself is a sliver, so I don't think we could do that easily.

[matthew-carroll]

@angelosilvestre it may not be easy, but I think the goal of this ticket is to have a reader that doesn't include scrolling. The scrolling internals interfere with the broader widget tree, and they also make things way more complicated.

So let's try to create a reader with an intrinsically sized document layout, no scrolling system, and then gestures on top of that. I think most of the work comes down to copying the existing layout widget, removing scrolling, copying the existing reader widget, removing scrolling.

If you hit major roadblocks while trying to do that then please let me know.

Also, I know I asked you to call it a SuperChatBubble cause we're gonna use it in chat, but then I got to thinking that we'll want something similar for the editor. So I think we should refer to the layout as SuperMessage and then we'll have a SuperMessageReader, and eventually we'll have something like a SuperMessageEditor.

[angelosilvestre]

@matthew-carroll Are you saying that, for this widget, we should use the older ContentLayers that is not a Sliver?

[matthew-carroll]

Are you saying that, for this widget, we should use the older ContentLayers that is not a Sliver?

Yeah, I guess that'll have to happen. I think we're just gonna have to maintain some parallel implementations so we can have with-scrolling and without-scrolling options.