Grid minimum dimensions are sometimes not respected

[bow]

I am encountering a problem with how grids handle different screen sizes. When grids contain other containers (e.g. other grids or flex containers), it seems to respond to the screen size only intermittently. That is, sometimes it shows the correct items, sometimes it show items meant for other sizes.

My starting point is the grid demo. I can run that perfectly fine; the visible items do change based on my terminal size. I am running on Linux, using Alacritty version 0.12.3.

The problem then showed up when running the following code:

// main.go
package main

import (
    "github.com/rivo/tview"
)

func main() {
    newBox := func(title string) tview.Primitive {
        return tview.NewBox().SetBorder(true).SetTitle(title)
    }

    narrow := tview.NewFlex().
        SetDirection(tview.FlexRow).
        AddItem(newBox("Narrow"), 0, 1, false).
        AddItem(newBox("Narrow"), 0, 1, false).
        AddItem(newBox("Narrow"), 0, 1, false)

    wide := tview.NewFlex().
        SetDirection(tview.FlexColumn).
        AddItem(newBox("Wide"), 0, 1, false).
        AddItem(newBox("Wide"), 0, 1, false)

    footer := tview.NewTextView().
        SetTextAlign(tview.AlignCenter).
        SetText("Footer")

    grid := tview.NewGrid().
        SetColumns(0).
        SetRows(0, 1).
        SetBorders(true).
        AddItem(footer, 1, 0, 1, 1, 0, 0, false)

    // Narrow screen layout.
    grid.AddItem(narrow, 0, 0, 1, 1, 0, 0, false)
    grid.AddItem(wide, 0, 0, 0, 0, 0, 0, false)

    // Wider screen layout
    grid.AddItem(wide, 0, 0, 1, 1, 0, 150, false)
    grid.AddItem(narrow, 0, 0, 0, 0, 0, 150, false)

    if err := tview.NewApplication().SetRoot(grid, true).EnableMouse(true).Run(); err != nil {
        panic(err)
    }
}

The problem showed up when running the code in a terminal wider than 150 columns (the minGridWidth value set above):

1. Notice that most (not always) of the time, the correct layout (two Wide boxes) are rendered.
2. Regardless of what is rendered, press any keyboard key (e.g. h) multiple times. Sometimes the narrow layout will be shown instead.
3. The above can also be triggered when holding (instead of pressing) the keyboard key. In this case, the wrong layout will flicker several times.

There is also another case, that is when resizing from a smaller terminal to a larger one. This, too, sometimes results in the narrow layout being rendered.

I could not reproduce these two problems with the demos/grid/main.go file. There, all the components are always rendered correctly. This lead me to think that it is the flex containers being nested inside a grid that is the problem (the demo file nests non-containers instead). However, I am not sure if this is it nor how to fix / work around this.

Any pointers and / or suggestions?

(P.S. Thanks for developing tview by the way!)

[WhipMeHarder]

My apologies to you, Box, for interjecting in your issue problems as defined here, as I am also encountering problems with the grid control. I am having the same/similar problems with grid control items not maintaining their dimension size integrity. Especially, when the grid has a column of 3 x 4 boxes placed with it. It does not seem to matter what dimension variations are placed within it, the grid control seems to be limited to having only 9 boxes placed within it. - Even then, there are "severe" size limitations to the box dimensions, otherwise everything becomes unstable. More importantly, the boxes then can only be set at a size where they are not practical to be used.

I have tested your code in Windows 10. My terminal has 237 columns, as seen here:

`Status for device CON:

Lines:          9001
Columns:        237
Keyboard rate:  31
Keyboard delay: 1
Code page:      850`

Everything displays correctly.

[rivo]

@bow Indeed, the Grid component did not resolve overlapping grid items correctly. This should be fixed with the latest commit.

@WhipMeHarder If your problem persists after this bugfix, please open a separate issue, along with demo code to reproduce it.

[bow]

Thanks a lot @rivo. I can confirm the problem does not occur anymore with that commit.