build method

@override Widget build(BuildContext context)

Describes the part of the user interface represented by this widget.

The framework calls this method when this widget is inserted into the tree in a given BuildContext and when the dependencies of this widget change (e.g., an InheritedWidget referenced by this widget changes). This method can potentially be called in every frame and should not have any side effects beyond building a widget.

The framework replaces the subtree below this widget with the widget returned by this method, either by updating the existing subtree or by removing the subtree and inflating a new subtree, depending on whether the widget returned by this method can update the root of the existing subtree, as determined by calling Widget.canUpdate.

Typically implementations return a newly created constellation of widgets that are configured with information from this widget's constructor and from the given BuildContext.

The given BuildContext contains information about the location in the tree at which this widget is being built. For example, the context provides the set of inherited widgets for this location in the tree. A given widget might be built with multiple different BuildContext arguments over time if the widget is moved around the tree or if the widget is inserted into the tree in multiple places at once.

The implementation of this method must only depend on:

• the fields of the widget, which themselves must not change over time, and
• any ambient state obtained from the context using BuildContext.dependOnInheritedWidgetOfExactType.

If a widget's build method is to depend on anything else, use a StatefulWidget instead.

See also:

• StatelessWidget, which contains the discussion on performance considerations.

Implementation

@override
Widget build(BuildContext context) {
  final tasks = _order
      .where((t) => showSemanticTask || t != YOLOTask.semantic)
      .toList(growable: false);

  // Content-hug + centered (NOT full-width) so the control only uses the width it needs, like the iOS app. Wrapped in
  // a scale-down FittedBox: on narrow screens the 6 segments can exceed the available width, which makes
  // CupertinoSlidingSegmentedControl compute a negative per-segment width and crash (BoxConstraints NOT NORMALIZED,
  // w=-0.8). FittedBox lays the control out at its natural (unbounded) width, then scales it down to fit, so the
  // per-segment width never goes negative.
  return Center(
    child: FittedBox(
      fit: BoxFit.scaleDown,
      child: CupertinoSlidingSegmentedControl<YOLOTask>(
        groupValue: tasks.contains(currentTask) ? currentTask : tasks.first,
        // black @ 70% — matches `toolbar.backgroundColor = .black.withAlphaComponent(0.7)` from setupToolbar.
        backgroundColor: Colors.black.withValues(alpha: 0.7),
        // selected thumb at 18% white, matching the iOS lensControl selectedSegmentTintColor.
        thumbColor: Colors.white.withValues(alpha: 0.18),
        padding: const EdgeInsets.symmetric(horizontal: 2, vertical: 2),
        onValueChanged: (task) {
          if (task != null) onTaskChanged(task);
        },
        children: {
          for (final task in tasks)
            task: Padding(
              padding: const EdgeInsets.symmetric(horizontal: 2, vertical: 3),
              child: Text(
                _shortLabels[task] ?? task.name,
                style: TextStyle(
                  color: Colors.white,
                  // 11pt + tighter padding so the 6 short tabs (Det/Seg/Sem/Cls/Pose/OBB) don't span so wide.
                  fontSize: 11,
                  fontWeight: task == currentTask
                      ? FontWeight.w600
                      : FontWeight.w400,
                ),
              ),
            ),
        },
      ),
    ),
  );
}