[GH-ISSUE #921] Grid minimum dimensions are sometimes not respected #670

Closed
opened 2026-03-04 01:06:56 +03:00 by kerem · 3 comments
Owner

Originally created by @bow on GitHub (Nov 23, 2023).
Original GitHub issue: https://github.com/rivo/tview/issues/921

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!)

Originally created by @bow on GitHub (Nov 23, 2023). Original GitHub issue: https://github.com/rivo/tview/issues/921 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](https://github.com/rivo/tview/tree/7c9e464bac026809d043dda41727113178f278e7/demos/grid). 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: ```go // 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!)
kerem closed this issue 2026-03-04 01:06:56 +03:00
Author
Owner

@WhipMeHarder commented on GitHub (Nov 23, 2023):

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.

<!-- gh-comment-id:1824720271 --> @WhipMeHarder commented on GitHub (Nov 23, 2023): 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.
Author
Owner

@rivo commented on GitHub (Nov 26, 2023):

@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.

<!-- gh-comment-id:1826813094 --> @rivo commented on GitHub (Nov 26, 2023): @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.
Author
Owner

@bow commented on GitHub (Nov 26, 2023):

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

<!-- gh-comment-id:1826833734 --> @bow commented on GitHub (Nov 26, 2023): Thanks a lot @rivo. I can confirm the problem does not occur anymore with that commit.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/tview#670
No description provided.