Repository navigation
Notes
Currently, when using a grid as a layout, the library does not attempt to alter the children's actual shapes, nor does it attempt to redirect touch events. If you have children whose rectangular bounds overlap, and you set your own touch/click listeners on those children, they are going to behave like in any other layout: the one on top at the touch point, z-order-wise, wins.
If you do need your own listeners, it's best to ensure that the touchable/clickable children lie completely within their cell's bounds.
Since the coordinate system here skips every other cross index in a given line, grids with a row count and/or column count of 1 can behave unexpectedly. I wouldn't consider these particular setups as "grids", really, but rather than have weird lower bounds for indices, or specialized behavior for only a handful of cases, I'll explain what you should expect to see.
A default grid with one row and one column is what you'd think it should be, like in the first image here:
As previously mentioned, however, insetEvenLines changes the valid coordinate
set, so (0,0) doesn't even exist when that option is enabled, and a 1x1 grid
with even lines inset is empty, as is illustrated by the second image above.
The third image shows that second 1x1 grid with enableEdgeLines set to true.
You can see that (0,0) would be directly in the middle there, and the library
obligingly adds lines on all sides of the empty grid. This setup likely isn't
useful to anyone, but the library doesn't prohibit it.
Grids with one row or column and two of the other are also peculiar because the single line in one direction means that the second line in the other doesn't exist, so they each end up with only one (interior) cell. The examples below all have 1 row and 2 columns, with the same settings as the 1x1 discussed above.
The first default setup and the second one with even lines inset should both look as you might have expected from what has been shown so far. The third one with edge lines enabled might seem incorrect at first, since the previously missing column appears out of nowhere, but it's not that column that's been added; rather, it's two new rows, one above and one below.
Cells in lines that are in the same direction as the hex's orientation do not touch each other, so a single line looks like unconnected hexagons, as shown in the first image here:
Additionally, since the zeroth line is even, insetEvenLines will visually push
that line away from the component's edge, as you can see in the second image
above. The inset option does affect the other type, too – i.e., where the hex
orientation is perpendicular – like is shown in the last image above.