How will multiple grids affect how getBlits and handleEvent is called?
CellOutline will be implemented uniquely by each grid type, I think. The thing is, each grid would know the most efficient way of rendering it's own lattice. Though this would best be done by separating out the logic into each own class (e.g. there's a SquareGridCellOutline for SquareGrid). At that point though, it should be called a Lattice instead of CellOutline. But maybe Lattice is reserved for the different grid types now instead of the object that does rendering? Idk anymore...
There will be one universal puzzle.grid object that manages the delegation of pointer events across the different grids/lattices. It will have to compensate for the various different ways you have multiple grids:
Bifurcated/separate/sequential: You can have separate grids that are truly meant to be different puzzles with their own undo-history, and the "clear layer" action only affects one grid or the other. The bifurcated term comes from the fact that you might want to bifurcate a solution, and that requires a separate undo-redo and other things like that. When there are multiple grids as part of the setter's puzzle (instead of the solver's solution), then they might be sequential, i.e. you have to solve one before solving the next.
Connected/offset/adjacent: You can have grids that are "physically" separated but part of the same puzzle (another similar one is where one grid is off to the side with an example solved puzzle but the solver is unable to affect it (maybe I will allow affecting it, but it doesn't change answer check. Hmmm... Food for thought)). This also allows for adjacent lattices of different types (hex + square).
Mirrored/stitched: You can have grids where the lattices can stitch their borders together or intermesh in some way (in the far future, grids rotated in 3d space might be possible) (along those lines, grids could stitch to their own borders to allow wrapping around to the other side of itself like Flow Free Warp. Also, I was thinking about how I could do "draw at this position but also at +10 cells East" controls that allows for "place objects such that it solves both grids" sorta puzzles.),
Also, CellOutline layers/the grid layer should not be ethereal or at least not deleted or at least only "deleted" it only is ethereal.
Should I list a new layer for each grid if a puzzle has multiple? Also, come up with specific terms for the different types of grids.
DefaultPlacement (the replacement of defaultRenderOrder). Requires the grid to show as a layer first (not ethereal).
How will multiple grids affect how getBlits and handleEvent is called?
CellOutline will be implemented uniquely by each grid type, I think. The thing is, each grid would know the most efficient way of rendering it's own lattice. Though this would best be done by separating out the logic into each own class (e.g. there's a SquareGridCellOutline for SquareGrid). At that point though, it should be called a Lattice instead of CellOutline. But maybe Lattice is reserved for the different grid types now instead of the object that does rendering? Idk anymore...
There will be one universal puzzle.grid object that manages the delegation of pointer events across the different grids/lattices. It will have to compensate for the various different ways you have multiple grids:
Also, CellOutline layers/the grid layer should not be ethereal or at least not deleted or at least only "deleted" it only is ethereal.
Should I list a new layer for each grid if a puzzle has multiple? Also, come up with specific terms for the different types of grids.
DefaultPlacement (the replacement of defaultRenderOrder). Requires the grid to show as a layer first (not ethereal).
Make CellOutlineLayer not ethereal.