cc: @math1man

As per your comment, I added padding + semantics to individual buttons, screenshot in the description.

Nice! Looks great!

I'm afraid I couldn't quite parse the rationale for expandChildren. What's is the scenario where expandChildren is neccessary?

@HansMuller

Here in the code, toggle buttons are stretched to take all the available space to match the tallest widget

For this test

This makes toggle buttons take all the available space, and stretch and input paddings are not possible as a result.

Here on the left, buttons with constraints: const BoxConstraints.tightFor(width: 86, height: 32) are stretch to take 48.0 height.

On the right, all buttons are stretched to match the tallest widget with various size constraints. Code from Height of segmented control is determined by the tallest widget test.

Buttons with 32.0 height constraint (stretched to 48.0)	Buttons with various height constraints

import 'package:flutter/material.dart';

class Home extends StatefulWidget {
  const Home({Key? key}) : super(key: key);

  @override
  _HomeState createState() => _HomeState();
}

class _HomeState extends State<Home> {
  int selectedTabIndex = 0;

  @override
  Widget build(BuildContext context) {
    final ColorScheme colorScheme = Theme.of(context).colorScheme;
    return Scaffold(
      body: Center(
        child: Container(
          color: Colors.green.withOpacity(0.15),
          child: ToggleButtons(
            direction: Axis.horizontal,
            tapTargetSize: MaterialTapTargetSize.padded,
            isSelected: [
              selectedTabIndex == 0,
              selectedTabIndex == 1,
              selectedTabIndex == 2,
            ],
            onPressed: (int index) {
              setState(() {
                selectedTabIndex = index;
              });
            },
            borderRadius: const BorderRadius.all(Radius.circular(8)),
            selectedBorderColor: colorScheme.primary,
            selectedColor: colorScheme.primary,
            // expandChildren: true,
            children: <Widget>[
              Container(
                constraints: const BoxConstraints.tightFor(height: 100.0),
              ),
              Container(
                constraints: const BoxConstraints.tightFor(
                    height: 400.0), // tallest widget
              ),
              Container(
                constraints: const BoxConstraints.tightFor(height: 200.0),
              ),
            ],
          ),
        ),
      ),
    );
  }
}

void main() {
  runApp(const MaterialApp(home: Home()));
}

We need the buttons to take less than 48.0 as per specs (existing design), I added the Center widget so buttons are not stretched and they are allowed to have the actual size they have constrained to.

Buttons with 32.0	Buttons with various height constraints

We need buttons not to stretch and leave room for padding when height but as you can see on the right, all buttons are constrained when test expect the buttons to be stretched to match the tallest widget height, hence I added expandChildren which allows buttons to expand when needed. expandChildren basically adds Center widget to buttons so they are not stretched.

This might not be the best solution, if you have a better idea, please let me know, appreciate it

I'm testing this out now @TahaTesser, thanks for your patience. It looks like there are merge conflicts currently though, just FYI. :)

I also made another minor change, since result widget is not wrapped in input padding, We don't need to return it from the if-else statement every time, instead, I am returning the default configuration if the axis direction is the default.

hhttps://github.com/flutter/flutter/pull/101760/files#diff-153bdbb7a6739dd071bbb7b8230e3884dcb6cedbc21a78ef82c0e6a8166bb220R795-R811

Cool! I will take another look and run it against the internal test that caused it to be reverted just to be sure.

It looks like the previous test failure is fixed now internally, but we introduced some new ones here. I'll update once I know what broke these other tests.

Still working on resolving the test failures. I am hoping to have them sorted today, a customer has informed us that #97302 is a potential release blocker and this will fix it.

When you have a chance @TahaTesser can you update the before/after image in your OP? I think the mix up with x and y is what caused the unexpected image this morning. Thank you!

When you have a chance @TahaTesser can you update the before/after image in your OP? I think the mix up with x and y is what caused the unexpected image this morning. Thank you!

Restored :)

Update: I am just awaiting a few changes landing in google and then this can land. There were a few customer tests that were looking up the underlying RawMaterialButton.