[proposal] provide layout widget that enforces minimum height

[feinstein]

I see many widgets meant to make its child as big as it wants, like Expanded, Flexible, BoxConstraints.expand(), SizedBox.expand, but many times I want to set a widget to be as small as possible, analog to Android's wrap_content.

Sometimes I get rendering Exceptions because the framework can't calculate the size of a widget, as when using Row and Column together, as explained here. The solution presented is always to use Expanded, but what if I don't want that content to expand? What if I want it as small as it can be without clipping anything?

The solution is usually to use multiple Expanded and Spacer with different flex parameters, but still this isn't perfect as negotiating flex values isn't what we always want, as the Spacer will not vanish if the screen gets smaller, it will try to maintain it's proportionality, forcing my widget to get smaller.

Maybe I am missing something about the way the framework works, so then this would be lack of tutorials, or maybe the Framework is missing a ShrinkWrap widget (as this is a property of some widgets already) or something with a similar name, that will size the wrapped widget to be as small as it can be.

Example of a problem that could benefit from this here, as I couldn't find how to solve this, even with IntrinsicHeight.

[feinstein]

@iapicca could you tag this issue with some higher-priority tags? My question on StackOverflow is still unanswered, the only answers are more workarounds than actual Widget composition solutions.

I strongly feel the Framework doesn't provide a solution for this scenario yet and it's a basic behavior that should be implemented.

[mfarizon]

Hi, I have a similar problem, I'm trying to force the PageView to take the size of his current child. (I explained my case here : #29749).

In the documentation of the ShrinkWrappingViewPort class, I found :

ListView, PageView, GridView, and CustomScrollView, which combine Scrollable and ShrinkWrappingViewport into widgets that are easier to use.

As a matter of fact, ListView, GridView and CustomScrollView have a shrinkWrap property, but I can't see any mechanism to force the PageView widget to scale down to his current child size.
Is it a lack of the framework, is it because of performance/technical reason or did we missed something ? 🙈

[feinstein]

Here I am at this issue again and with a new case.

I have a widget that only controls which widget should be shown on screen, so if the user logs-out, this widget automatically takes the whole screen out of view and replaces it with the login screen. If the user logs-in, it replaces the login screen with the rest of the app.

Its structure looks something like this:

class HomeScreen extends StatefulWidget {
  @override
  _HomeScreenState createState() => _HomeScreenState();
}

class _HomeScreenState extends State<HomeScreen> {
  Widget currentScreen = SplashScreen(); // Only shows SplashScreen once.
  StreamSubscription<FirebaseUser> _subscription;

  @override
  void initState() {
    super.initState();
    // subscribes to a FirebaseAuth stream, getting new user login events, 
    // and calls setState with the new currentScreen
  }

  @override
  void dispose() {
    _subscription.cancel();
    super.dispose();
  }

  @override
  Widget build(BuildContext context) {
    return currentScreen;
  }
}

Now, I want to place a persistent red message on the bottom of the whole app, when there's no internet connectivity, so I changed the build method to:

  @override
  Widget build(BuildContext context) {
    return Column(
      children: <Widget>[
        Flexible(
          flex: 27,
          child: currentScreen,
        ),
        Flexible(
          child: ExpandedSection(
            expand: true,
            child: OfflineMessage(),
          ),
        ),
      ],
    );
  }

Whereas ExpandedSection is a widget that I made that expands if expand: is true with an animation. Since currentScreen will most likely be a a ListView, if I remove the Flexible I get rendering errors, from infinite height calculations. What I wanted was to be able to just let the framework know that currentScreen should expand as much as it wants, so long that ExpandedSection could have its smallest size, but IntrinsicHeight doesn't work either and since there are only widgets for informing about expansion, my only solution is to hard-code flex values.

Hard-coded flex values shouldn't be necessary for this kind of use cases and the Framework should provide an elegant way to send the information that something wants to Shrink as much as it wants.

[ciriousjoker]

Any news on this?

[ludwiktrammer]

@feinstein Could you explain why IntrinsicHeight isn't enough in the case that you described? It seems to me that something like this should work in general:

  @override
  Widget build(BuildContext context) {
    return Column(
      children: <Widget>[
        Expanded(
          child: currentScreen,
        ),
        IntrinsicHeight(
          child: ExpandedSection(
            child: OfflineMessage(),
          ),
        ),
      ],
    );
  }

(In fact in many cases it should work even after removing IntrinsicHeight - as long as ExpandedSection is not a widget that tries to expand to cover all its available height).

[ludwiktrammer]

More generally, I think that writing a design doc and working on this might be an interesting personal project for me. But I have a hard time understanding what exactly is being requested here.

If the new widget were to work on constraints, what would it do with them? Remember that constraints go from parent to children (i.e., down the tree) and not the other way around. There already is SizedBox.shrink which causes the widget to be as small as the parent allows. That mechanism doesn't take the child's wants and needs into account, but that's how it goes in Flutter - the parents set constraints without any feedback from the child, and then the child sizes itself within those constraints.

There is also an alternative mechanism that takes feedback from the child into account (which makes it more expensive). Widgets can be asked about their intrinsic height / width and that information is computed by going up the tree (i.e., the parent asks its child about the child's intrinsic size and calculates its own based on the answer). This seems to be more in line with what's being discussed in this ticket - that's the size that the given widget feels it needs to display its content, without any clipping. But widgets that force their child's size to equal the child's intrinsic height / width (within the constraints received from their parent, of course) already exist - IntrinsicHeight / IntrinsicWidth. So it isn't immediately clear what more is need.

Granted, there is a subtle distinction that IntrinsicHeight and IntrinsicWidth widgets hide. Widgets don't compute a single intrinsic height and a single intrinsic width. They compute a minimum intrinsic height, a maximum intrinsic height, a minimum intrinsic width, and a maximum intrinsic width. As I said, the distinction between the minimum and maximum values is quite subtle. For example, when it comes to text, the maximum intrinsic width would equal the width of the entire string rendered on one line. The minimum intrinsic width would equal the width of the widest word (i.e., it answers the question what is the smallest width that can be achieved by rendering the text on multiple lines, but without clipping or breaking lines in the middle of words).

IntrinsicHeight and IntrinsicWidth always use the maximum intrinsic values and ignore the minimal intrinsic values. So maybe this ticket should be interpreted as a request to surface the minimal values, for example by adding a parameter to IntrinsicHeight and IntrinsicWidth that would make them use the minimal intrinsic values instead?

I'm not convinced. Using the maximal intrinsic values seems like the right thing to do in most cases. That causes the widget to be sized to be fully comfortable, while still adhering to its parent's constraints. Staying with the text width example, wrapping Text in IntrinsicWidth would cause the widget to never be wider than the text it displays (assuming it's not forced to by wider by the parent's constraints - but that can be easily dealt with) but if the text is wider than the maximum width available to the widget, it would still be rendered in multiple lines. That's because the IntrinsicWidth widget causes the widget's width to equal the widget's maximum intrinsic width, but only as long it's within the boundaries available to the widget (i.e., within the constraints given by the parent). I think that is what you usually want.

And there is also the fact that many widgets (including Text) already behave as if they were wrapped in the Intrinsic* widgets - i.e., they take up only as much space as they need, as long as they are not forced to do otherwise by their parent's constraints. So many times you don't even need to use Intrinsic* to have a widget not expand beyond what's needed. It's just a matter of not using a parent that would force it to do so by setting minimum constraints (like Expanded or SizedBox). And of course there are widgets that can reset the minimum constraints for their children by taking upon themselves the responsibility of taking up any remaining unused space (like Align).

So I'm curious:

1. What are the exact use cases for the new widget?
2. If the widget were to work on constraints, how would it differ from SizedBox.shrink, while adhering the model used by Flutter (which says that constraints are passed down the tree).
3. Are there any real-world use cases that would make adding a new parameter to IntrinsicWidth and IntrinsicHeight worthwhile? In this scenario, the parameter would cause them to use minimal intrinsic values instead of the maximal intrinsic values that they use by default.

[ludwiktrammer]

As to the potential use case mentioned by @mfarizon (the PageView one). I think this is more of a feature request regarding the PageView widget itself. I don't think anything will ever change the fact that it's the widget's responsibility to compute its own size and that it's the widget's responsibility to compute its intrinsic width and height.

Currently, PageView sizes itself to take up all the available space and it doesn't support returning intrinsic dimensions at all. Theoretically speaking, you could have an attribute on PageView that would cause it to behave differently in that regard (note that this would be somewhat different from the shrinkWrap attribute on widgets such since shrinkWrap affects the main axis while you want PageView to be sized differently on the cross axis).