Make layout flexibility of catalog items explicit, transparent for LLM, and visible for the host application.

_↴ Ported from [flutter/genui#397](https://github.com/flutter/genui/issues/397) — originally opened by [polina-c](https://github.com/polina-c) on 2025-10-18._
_Original labels: P2, c: ebb_

---

It should be clear if a catalog item has fixed size or wants to take all available space.
So that, the container that renders SurfaceWidget know which option to choose:

* for fix sized: provide scrollable area
* fir flexible: limit the size

API that may work:

```dart
class Flexibility {
final bool horizontal;
final bool vertical;
}

Flexibility GenUiHost.surfaceFlexibility(surfaceId);

Flexibility get CatalogItem.flexibility
```

And the declared flexibility of the items should be test covered.

Right now these two widgets of the core catalog do not play well in chat area, because they want to take all the space, so I am excluding them in my app:

```dart
// Removed items that are flexible,
// so they do not work well in chat context.
CoreCatalogItems.asCatalog().copyWithout([
CoreCatalogItems.tabs,
CoreCatalogItems.list,
]),
```

---

### 2 comment(s) from the original issue

**[jacobsimionato](https://github.com/jacobsimionato)** commented on 2025-12-01:

I think instead of declaring the flexibility here, I think we should try to implement the widgets such that any widget can be placed inside any container e.g. by setting upper limits for widgets that have unconstrained upper bounds to width and height.

I haven't though this through in great detail, so we should do some analysis, but the idea here is that we should make it easy for the LLM to make valid layouts. In HTML, you can pretty much nest things however you like and the browser nearly always renders something semi-reasonable, and without any huge red boxes. Let's do the same for Gen UI.

I'm curious what you think @polina-c !

BTW I already reimplemented tabs so that it doesn't break like this.

Re list: I think it should only expand to the size of its contents, but then if the host app doesn't give it enough space, then we start scrolling. Not sure if that is easy to do.

---

**[polina-c](https://github.com/polina-c)** commented on 2025-12-04:

@jacobsimionato

Thanks for commenting.

"setting upper limits for widgets that have unconstrained upper bounds to width and height" - this does not seem to produce good UX

For example, the app may want to render the same GenUI surface (let's say tabs) in both chat area and canvas area. The UX maybe: first tabs appear in chat, and then user decides to pin the tabs to canvas area on the right in order to discuss the content deeper with LLM.

In the **chat area** we want the tabs to take exactly needed vertical space, so that (1) there is no nested vertical scroll and (2) it does not take more space in the chat than needed.

In the **canvas area** each pinned artifact is named and accessible by name, and when selected, we want it to take the entire space, and, if it does not fit, to provide vertical scroll.

If we just 'set upper limits', yes, there will not be runtime error, but the tabs will look bad in both cases.

Am I missing something?

May point is: **we do not want LLM to worry about layout**. All these layout decisions should be made deterministically by the host application, without input from LLM.

Look at the core catalog items, especially tabs and list, to understand their current layout behavior. Examine how SurfaceWidget renders items and where layout decisions are made. The goal is to add a flexibility property to CatalogItem and surfaceFlexibility to GenUiHost, then test that fixed-size items get scrollable areas and flexible items are limited. Start by finding the catalog item definitions and the surface rendering logic.

Escrito por el modelo de indexación a partir del texto del issue.