TableColumnWidthdescribes the width of a single column in a
RenderTable. Implementations can produce a flex factor for the column (via
TableColumnWidth.flex, which may iterate over every cell) as well as a maximum and minimum intrinsic width (via
TableColumnWidth.minIntrinsicWidth, which also have access to the incoming maximum width constraint). Intrinsic dimensions are expensive to compute since they typically visit the entire subtree for each cell in the column. Subclasses implement a subset of these methods to provide different mechanisms for sizing columns.
FixedColumnWidthproduces tight intrinsic dimensions, returning the provided constant without additional computation.
FractionColumnWidthapplies a fraction to the incoming maximum width constraint to produce tight intrinsic dimensions. If the incoming constraint is unbounded, the resulting width will be zero.
TableColumnWidthinstances, returning the greater or lesser value produced by each method, respectively.
FlexColumnWidthreturns the specified flex value which corresponds to the portion of free space to be utilized by the column (i.e., free space is distributed according to the ratio of the column’s flex factor to the total flex factor). The intrinsic width is set to zero so that the column does not consume any inflexible space.
IntrinsicColumnWidthis the most expensive strategy, sizing the column according to the contained cells’ intrinsic widths. A flex factor allows columns to expand even further by incorporating a portion of any unclaimed space. The minimum and maximum intrinsic widths are defined as the maximum value reported by all contained render boxes (via
RenderBox.getMaxIntrinsicWidthwith unbounded height).
TableCellVerticalAlignmentspecifies how a cell is positioned within a row. Top and bottom ensure that the corresponding side of the cell and row are coincident, middle vertically centers the cell, baseline aligns cells such that all baselines are coincident (cells lacking a baseline are top aligned), and fill sizes cells to the height of the cell (if all cells fill, the row will have zero height).
TableBorderdescribes the appearance of borders around and within a table. Similar to
BorderSideinstances for each of the cardinal directions (
TableBorder.bottom, etc). In addition,
TableBorderdescribes the seams between rows (
TableBorder.horizontalInside) and columns (
TableBorder.verticalInside). Borders are painted via
TableBorder.paintusing row and column offsets determined by layout (e.g., the number of pixels from the bounding rectangle’s top and left edges for horizontal and vertical borders; there will be one entry for each interior seam).
RenderTableaccepts a list of decorations to be applied to each row in order. These decorations span the full extent of each row, unlike any cell-based decorations (which would be limited to the dimensions of the cell; cells may be offset within the row due to
BoxParentDatato include the cell’s vertical alignment (via
TableCellVerticalAlignment) as well as the most recent zero-indexed row and column numbers (via
TableCellParentData.x, respectively). The cell’s coordinates are set during
RenderTablelayout whereas the vertical alignment is set by
RenderTableis a render box implementing table layout and painting. Columns may be associated with a sizing strategy via a mapping from index to
columnWidths); a default strategy (
defaultColumnWidth) and default vertical alignment (
defaultVerticalAlignment) round out layout. The table is painted with a border (
TableBorder) and each row’s full extent may be decorated (
RenderBoxchildren are passed as a list of rows; internally, children are stored in row-major order using a single list. The number of columns and rows can be inferred from the child list, or specifically set. If these values are subsequently altered, children that no longer fit in the table will be dropped.
RenderTable.setFlatChildren), using a column count to divide cells into rows. New children are adopted (via
RenderBox.adoptChild) and missing children are dropped (via
RenderBox.dropChild); children that are moved are neither adopted nor dropped. Children may also be added using a list of rows (via
RenderTable.setChildren); this clears all children before adding each row incrementally (via
RenderTable.addRow). Note that this may unnecessarily drop children, unlike
TableColumnWidthinstances describe how each column consumes space in the table. During layout, these instances are used to produce concrete widths given the incoming constraints (via
TableColumnWidthand passing the maximum width constraint as well as all contained cells.
RenderTable._computeColumnWidths) using the width argument as a tight constraint.
RenderBox.getMaxIntrinsicHeight) using the calculated column width. The maximum row heights are summed to produce the table’s intrinsic height.
RenderTable._columnLefts). The copy of this list used by layout is flipped for right-to-left locales. The overall table width is defined as the sum of all columns widths (e.g., the last column x-coordinate plus the last column’s width).
RenderTable._rowTops). Child layout proceeds as this list is calculated (i.e., row-by-row).
RenderTable._rowTops) is cleared and seeded with an initial y-coordinate of zero (i.e., layout starts from the origin along the y-axis). The current row height is zeroed as are before- and after-baseline distances. These values track the maximum dimensions produced as cells within the row are laid out. The before-baseline distance is the maximum distance from a child’s top to its baseline; the after-baseline distance is the maximum distance from a child’s baseline to its bottom.
RenderBox.getDistanceToBaseline) update the baseline distances to be at least as large as the child’s values.
RenderTable._rowDecorations) is painted via
Decoration.createBoxPainter. Decorations are positioned using the incoming offset and the list of row tops (