What's the width of a greedy widget that comes after a widget that already exceeded available space?

[amano-kenji]

Does the greedy widget grow very large? Or, does it become emptyWidget and avoid calculating its contents?

Let's assume that the given horizontal space is 15, but a widget in hBox already consumes 16.
If a horizontally greedy widget comes after it, what is going to be its width?

This is the minimal example.

module Main where

import Brick.Types
import Brick.Widgets.Core
import Brick.Widgets.Center
import Brick.Widgets.Border
import Brick.Main
import Brick.AttrMap
import Graphics.Vty.Attributes (defAttr)
import Graphics.Vty.Input
import Control.Monad (void)

drawUi :: () -> [Widget ()]
drawUi () = let
  greedyText = Widget Greedy Fixed $ do
    render $ hCenter $ str "ok"
  mainW = border $ hLimit 15 $ hBox [greedyText, str "1234567890", greedyText, str "123456", greedyText]
  doc = str "Prsss Esc to quit"
  in [ vCenter $ vBox [ hCenter mainW, hCenter doc ] ]

handleEvent :: BrickEvent () () -> EventM () () ()
handleEvent e = case e of
  VtyEvent (EvKey KEsc _) -> halt
  _ -> return ()

main :: IO ()
main = do
  let app = App { appDraw = drawUi
                , appChooseCursor = neverShowCursor
                , appHandleEvent = handleEvent
                , appStartEvent = return ()
                , appAttrMap = const $ attrMap defAttr [] }
  void $ defaultMain app ()

This is what I see.

The first two greedyTexts are not rendered. But, I don't know whether or not the third greedyText is rendered because it is cropped out of hLimit 15.

[amano-kenji]

https://github.com/jtdaugherty/brick/blob/master/docs/guide.rst says

rendering the box layout algorithm has to be careful about rendering such Greedy widgets because they won't leave room for anything else. Since the box widget cannot know the sizes of its sub-widgets until they are rendered, the Fixed widgets get rendered and their sizes are used to determine how much space is left for Greedy widgets.

Thus, it seems the third greedyText widget is knocked out and not rendered.

The basics seem to be understood only after writing some code and reading the documentation multiple times.

[jtdaugherty]

Something I want to point out about your example is that a widget can advertise a growth policy (e.g. Greedy) that doesn't actually match its implementation. In your example, greedyText declares itself greedy but does not actually behave that way because it does not use the rendering context to draw itself as large as possible in the greedy dimension(s). The consequence of that is that it will affect box rendering order (as already discussed) but won't look the way it "should" because the widget's behavior isn't matching its growth declaration.

[jtdaugherty]

Let's assume that the given horizontal space is 15, but a widget in hBox already consumes 16.
If a horizontally greedy widget comes after it, what is going to be its width?

The box layout algorithm always renders Fixed widgets first, then gives any remaining space to Greedy ones. So if a box contains two widgets Fixed A and Greedy B and A uses all the space in the box, B gets none if A uses all the space.

[jtdaugherty]

I just pushed c164f17 to improve the vBox and hBox docs along these lines.