Question about styling with multiple concurrent states

[LiamGoodacre]

Off the back of this tweet, I'm wondering how you would go about implementing this.

I have a sudoku game.
Each cell has multiple concurrent states which can affect how the cells should look:

• Content = "given" | "input" | "blank"
  • "given": cell has a given preset digit
  • "input": cell has a user entered digit
  • "blank": cell has no digit (but may have marks)
• Matched = "nomatch" | "match"
  • cell matches digits we're highlighting (e.g, highlight all the 5s)
• Selected = "noselect" | "select"
  • multiple cells can be selected to be input at the same time
• Focussed = "nofocus" | "focus"
  • a single cell has focus, which is the main cell being interacted with

For example, a cell could be all of: input, matched, selected, and focussed at the same time.

I wanted to style with the following pseudocode rules (later rules have greater priority):

• cells default to a white background
• "match"ing cells have bold text and a green background
• "select"ed cells have a cyan background
• cells with "focus": the background switches to bright
• cells with "given" content: have a black foreground
• cells with "blank" or "input" content: have a blue foreground

I do have something which "works" and is somewhat pleasing to use, but I would like to understand how someone more in the know would tackle this scenario.

---

Edit

Here's roughly what I'm currently using:

cellAttrMap :: [(Brick.AttrName, Vty.Attr)]
cellAttrMap =
  cascade
    [ rule withCell [BackColour .== Vty.white],
      rule (withMatched [True]) [ IsBold .== True, BackColour .== Vty.green ],
      rule (withSelected [True]) [BackColour .== Vty.cyan],
      rule (withFocussed [True]) [BackBright .== True],
      rule (withContent [CellContentGiven]) [ForeColour .== Vty.black],
      rule (withContent [CellContentBlank, CellContentInput]) [ForeColour .== Vty.blue]
    ]

I'm generating attribute map entries for each possible combination of states.

In which the with* functions define a "pattern", by specifying which refinement of states the rule applies to.
So withMatched [True] means { matched is True, selected is *, focussed is *, content is * }, i.e 12 different attribute names.

The rules apply in order; and the rule "body" defines a transformation to apply – letting me specify, for example, that the background colour should become bright in the focussed case.

For any two identical rule patterns, the transformations are composed – such that later modifications take priority.

To see the full code look at lines 229-411 of this file.

---

Edit 2

I've simplified this a lot.

data CellState t = CellState
  { cellGiven :: t,
    cellMatched :: t,
    cellSelected :: t,
    cellFocussed :: t
  }
  deriving stock (Foldable, Functor, Traversable)

instance Applicative CellState where
  pure v = CellState v v v v
  l <*> r =
    CellState
      { cellGiven = cellGiven l (cellGiven r),
        cellMatched = cellMatched l (cellMatched r),
        cellSelected = cellSelected l (cellSelected r),
        cellFocussed = cellFocussed l (cellFocussed r)
      }

instance Universe t => Universe (CellState t) where
  universe = sequence $ pure universe

cellStateName :: CellState Bool -> Brick.AttrName
cellStateName CellState {..} = do
  let flag :: String -> Bool -> String
      flag m b = show (m, b)
  foldMap
    Brick.attrName
    [ "cell",
      flag "match" cellMatched,
      flag "select" cellSelected,
      flag "focus" cellFocussed,
      flag "given" cellGiven
    ]

cellStateStyle :: CellState Bool -> Vty.Attr -> Vty.Attr
cellStateStyle CellState {..} = do
  let (.==>.) b v = if b then v else id
  compose $
    reverse
      [ onAttrBackColor .~ Vty.SetTo Vty.white,
        cellMatched .==>. (`Vty.withStyle` Vty.bold),
        cellMatched .==>. (onAttrBackColor .~ Vty.SetTo Vty.green),
        cellSelected .==>. (onAttrBackColor .~ Vty.SetTo Vty.cyan),
        onAttrBackColor . onPreviouslySet %~ (cellFocussed .==>. brightISO),
        onAttrForeColor .~ Vty.SetTo if cellGiven then Vty.black else Vty.blue
      ]

cellStateAttrMap :: [(Brick.AttrName, Vty.Attr)]
cellStateAttrMap =
  universe @(CellState Bool) <&> \cellState ->
    (cellStateName cellState, cellStateStyle cellState Vty.defAttr)

[jtdaugherty]

If it were me, I would probably use attributes to indicate some of those states and textual decorations to indicate others. Since that is a lot of potential simultaneous states to be in, I'd be concerned that trying to use attributes to indicate them all would be hard to get right and also hard to be visibly usable. (E.g. I might put > ... < or [...] around the cell's content to indicate focus if attributes were being used to indicate other things.)

But, with that said, assuming an approach based solely on attributes, if you want to have later rules take priority, then I think that's a job for attribute name hierarchy, e.g.,

cellBaseAttr, matchAttr, selectedAttr, focusAttr, givenAttr, blankOrInputAttr :: AttrName
cellBaseAttr = attrName "cell"
matchAttr = cellBaseAttr <> attrName "match"
selectedAttr = matchAttr <> attrName "selected"
focusAttr = selectedAttr <> attrName "focus"
givenAttr = focusAttr <> attrName "given"
blankOrInputAttr = givenAttr <> attrName "blankOrInput"

Then, in the drawing code itself, for each cell, use withDefAttr and one of the above attribute names based on the state of the cell in question. Written this way, givenAttr is a more specific version of focusAttr and so on, meaning that when a lookup for focusAttr is performed, any color or style information found in the attribute map is merged with (and takes precedence over) any information found in the attribute map for the parent name. So, for example, if givenAttr sets a foreground color in the attribute map, that will take precedence over the foreground colors specified for any of focusAttr, selectedAttr, etc.

[jtdaugherty]

I also want to add that using that approach might still lead to undesired or unexpected consequences if there are ever any cells whose states do not conform exactly to the precedence relationship you outlined, so this still might be tricky to do.

[jtdaugherty]

Which is one reason why whatever you're already doing might be a better way; I probably would not do this by using the attribute map lookup to handle precedence for exactly the reason that it could be hard to manage the cartesian product of many possible cell states. But this is potentially one way to do it.

[LiamGoodacre]

Thanks for sharing your thoughts & suggestions on this.
I've updated my original post with some additions as things have developed.
I think I'm rather happy with where I've ended up.

[jtdaugherty]

Okay, great!