[GH-ISSUE #708] Feature Request: GetRoot() for *tview.Application #517

New issue

Closed

opened 2026-03-04 01:05:40 +03:00 by kerem · 3 comments

kerem commented

2026-03-04 01:05:40 +03:00

Owner

Originally created by @demont93 on GitHub (Mar 12, 2022).
Original GitHub issue: https://github.com/rivo/tview/issues/708

I'm sure there is a reason why this function doesn't exist. I am not questioning the design of the library, I'm just wondering what that reason is and what would be an alternative in the following case.

Say I want to display a warning message in a modal. My initial impulse would be to pass the application to a function which gets the current root, then sets the root to a frame containing the modal, and finally sets the selectedFunc on the modal to return root to previous root.

Please be nice I am starting to learn these concepts. I am in no way an expert tui or gui programmer.

Originally created by @demont93 on GitHub (Mar 12, 2022). Original GitHub issue: https://github.com/rivo/tview/issues/708 I'm sure there is a reason why this function doesn't exist. I am not questioning the design of the library, I'm just wondering what that reason is and what would be an alternative in the following case. Say I want to display a warning message in a modal. My initial impulse would be to pass the application to a function which gets the current root, then sets the root to a frame containing the modal, and finally sets the selectedFunc on the modal to return root to previous root. Please be nice I am starting to learn these concepts. I am in no way an expert tui or gui programmer.

kerem closed this issue

2026-03-04 01:05:41 +03:00

kerem commented

2026-03-04 01:05:41 +03:00

Author

Owner

@codeactual commented on GitHub (Mar 12, 2022):

The approach I'm currently using is based on https://pkg.go.dev/github.com/rivo/tview#Pages:

Pages is a container for other primitives laid out on top of each other, overlapping or not. It is often used as the application's root primitive. It allows to easily switch the visibility of the contained primitives.

I use Pages as the "root" because its API lets me do things like control which one is in "front" (in my case, all pages take up the whole screen) and reference them by name string in many of the methods.

So in that model:

Your current non-model "screen" might be represented as a page.
The modal might also be represented as a page that is temporarily added in "front" and given focus (maybe with AddAndSwitchToPage) then later discarded by RemovePage or HidePage, returning display/focus back to the initial page/screen.

The second example in https://github.com/rivo/tview/wiki/Modal shows this in action where the "background" view would be that initial screen/page which you want to return to at the end.

@codeactual commented on GitHub (Mar 12, 2022): The approach I'm currently using is based on https://pkg.go.dev/github.com/rivo/tview#Pages: > Pages is a container for other primitives laid out on top of each other, overlapping or not. It is often used as the application's root primitive. It allows to easily switch the visibility of the contained primitives. I use `Pages` as the "root" because its API lets me do things like control which one is in "front" (in my case, all pages take up the whole screen) and reference them by `name string` in many of the methods. So in that model: - Your current non-model "screen" might be represented as a page. - The modal might also be represented as a page that is temporarily added in "front" and given focus (maybe with `AddAndSwitchToPage`) then later discarded by `RemovePage` or `HidePage`, returning display/focus back to the initial page/screen. The second example in https://github.com/rivo/tview/wiki/Modal shows this in action where the "background" view would be that initial screen/page which you want to return to at the end.

kerem commented

2026-03-04 01:05:41 +03:00

Author

Owner

@demont93 commented on GitHub (Mar 13, 2022):

The second example in https://github.com/rivo/tview/wiki/Modal shows this in action where the "background" view would be that initial screen/page which you want to return to at the end.

This is exactly what I was looking for. Thank your for taking the time to answer my question in such an informative and detailed way. I will go ahead and close the issue.

@demont93 commented on GitHub (Mar 13, 2022): > The second example in https://github.com/rivo/tview/wiki/Modal shows this in action where the "background" view would be that initial screen/page which you want to return to at the end. This is exactly what I was looking for. Thank your for taking the time to answer my question in such an informative and detailed way. I will go ahead and close the issue.

kerem commented

2026-03-04 01:05:42 +03:00

Author

Owner

@rivo commented on GitHub (Mar 13, 2022):

Thanks, @codeactual, that's how it was intended. But as for your question, @demont93:

I'm just wondering what that reason is

Basically, it's to reduce dependencies within the package. There are only top-down dependencies and usually only by one level. E.g. an application has a pointer to its displayed element. That element may have pointers to its child elements. But they don't contain pointers back to their parents or even the application itself. In the long run, it would make things quite messy if they did.

Of course, users may keep their own references to parent components. That's sometimes even necessary. But tview itself is strictly hierarchical.

For switching views or laying out multiple components, there is Pages, Grid, and Flex.

@rivo commented on GitHub (Mar 13, 2022): Thanks, @codeactual, that's how it was intended. But as for your question, @demont93: > I'm just wondering what that reason is Basically, it's to reduce dependencies within the package. There are only top-down dependencies and usually only by one level. E.g. an application has a pointer to its displayed element. That element may have pointers to its child elements. But they don't contain pointers back to their parents or even the application itself. In the long run, it would make things quite messy if they did. Of course, users may keep their own references to parent components. That's sometimes even necessary. But `tview` itself is strictly hierarchical. For switching views or laying out multiple components, there is `Pages`, `Grid`, and `Flex`.