[GH-ISSUE #79] Forms can grow beyond terminal dimensions #59

Closed
opened 2026-03-04 01:01:32 +03:00 by kerem · 19 comments
Owner

Originally created by @joegrasse on GitHub (Mar 14, 2018).
Original GitHub issue: https://github.com/rivo/tview/issues/79

If you add too many form items to a form, it can vertically grow beyond the terminal's height. It would be nice if one could scroll within a form in such a case.

Originally created by @joegrasse on GitHub (Mar 14, 2018). Original GitHub issue: https://github.com/rivo/tview/issues/79 If you add too many form items to a form, it can vertically grow beyond the terminal's height. It would be nice if one could scroll within a form in such a case.
kerem closed this issue 2026-03-04 01:01:32 +03:00
Author
Owner

@rivo commented on GitHub (Mar 15, 2018):

Thanks for the hint. I just fixed this.

<!-- gh-comment-id:373447590 --> @rivo commented on GitHub (Mar 15, 2018): Thanks for the hint. I just fixed this.
Author
Owner

@joegrasse commented on GitHub (Mar 15, 2018):

This works as long as you don't specifically set the Form's Box size. See issue #81 as to why you might do that.

<!-- gh-comment-id:373456220 --> @joegrasse commented on GitHub (Mar 15, 2018): This works as long as you don't specifically set the Form's Box size. See issue #81 as to why you might do that.
Author
Owner

@joegrasse commented on GitHub (Mar 15, 2018):

@rivo Looks like you still can set the Form's Box size just as long as it is less than the terminal window size. When you set the Box size bigger than the terminal size, that is when this change no longer works.

<!-- gh-comment-id:373459563 --> @joegrasse commented on GitHub (Mar 15, 2018): @rivo Looks like you still can set the Form's Box size just as long as it is less than the terminal window size. When you set the Box size bigger than the terminal size, that is when this change no longer works.
Author
Owner

@rivo commented on GitHub (Mar 15, 2018):

See #81 for details about layouts in tview.

Setting a box to a size larger than the screen will lead to undefined effects.

<!-- gh-comment-id:373466237 --> @rivo commented on GitHub (Mar 15, 2018): See #81 for details about layouts in `tview`. Setting a box to a size larger than the screen will lead to undefined effects.
Author
Owner

@joegrasse commented on GitHub (Mar 15, 2018):

Ok, maybe you can clarify something then. If do form.SetRect( to change the Forms size, this change doesn't work, but if I do form.Box.SetRect(, this change works. Why would that be? (See next comment)

<!-- gh-comment-id:373472694 --> @joegrasse commented on GitHub (Mar 15, 2018): ~~Ok, maybe you can clarify something then. If do ```form.SetRect(``` to change the Forms size, this change doesn't work, but if I do ```form.Box.SetRect(```, this change works. Why would that be?~~ (See next comment)
Author
Owner

@joegrasse commented on GitHub (Mar 15, 2018):

@rivo Sorry for the multiple comments, but I noticed something. Even without changing the Form's Box size the default Box can be bigger than the terminal size (granted unlikely). Under this condition though this change still doesn't work as expected. So my setting of the Form's box size explicitly wasn't what was causing this change to not work.

<!-- gh-comment-id:373476409 --> @joegrasse commented on GitHub (Mar 15, 2018): @rivo Sorry for the multiple comments, but I noticed something. Even without changing the Form's Box size the default Box can be bigger than the terminal size (granted unlikely). Under this condition though this change still doesn't work as expected. So my setting of the Form's box size explicitly wasn't what was causing this change to not work.
Author
Owner

@joegrasse commented on GitHub (Mar 15, 2018):

@rivo Ok, I believe I have discovered the issue. I will submit a pull request for you to look at.

<!-- gh-comment-id:373485965 --> @joegrasse commented on GitHub (Mar 15, 2018): @rivo Ok, I believe I have discovered the issue. I will submit a pull request for you to look at.
Author
Owner

@rivo commented on GitHub (Mar 15, 2018):

Can you explain why you're setting the Form to a size that exceeds the screen?

None of the primitives are made for this case (and fixing it only in the Form class introduces an inconsistency which I'm not particularly happy about).

<!-- gh-comment-id:373497384 --> @rivo commented on GitHub (Mar 15, 2018): Can you explain why you're setting the `Form` to a size that exceeds the screen? None of the primitives are made for this case (and fixing it only in the `Form` class introduces an inconsistency which I'm not particularly happy about).
Author
Owner

@joegrasse commented on GitHub (Mar 15, 2018):

The issue exists even if I don't set the form size. The box default size can be bigger than the screen size, and in this situation keeping the form item in focus didn't work.

<!-- gh-comment-id:373498890 --> @joegrasse commented on GitHub (Mar 15, 2018): The issue exists even if I don't set the form size. The box default size can be bigger than the screen size, and in this situation keeping the form item in focus didn't work.
Author
Owner

@joegrasse commented on GitHub (Mar 15, 2018):

The end user can also resize the terminal which can cause the form/box size to be bigger than the screen.

<!-- gh-comment-id:373499910 --> @joegrasse commented on GitHub (Mar 15, 2018): The end user can also resize the terminal which can cause the form/box size to be bigger than the screen.
Author
Owner

@rivo commented on GitHub (Mar 16, 2018):

Again, this is what Flex and Grid are for. They adjust their size according to the screen, even when the user resizes it. I would go so far as to say that calling SetRect() or using the default size of a primitive is something most applications will never do.

Check out the demo in the demos/form/ directory. You can resize the screen and the form will always adjust. And with the new modifications, the currently selected form field will always be in view.

<!-- gh-comment-id:373618704 --> @rivo commented on GitHub (Mar 16, 2018): Again, this is what `Flex` and `Grid` are for. They adjust their size according to the screen, even when the user resizes it. I would go so far as to say that calling `SetRect()` or using the default size of a primitive is something most applications will never do. Check out the demo in the `demos/form/` directory. You can resize the screen and the form will always adjust. And with the new modifications, the currently selected form field will always be in view.
Author
Owner

@joegrasse commented on GitHub (Mar 16, 2018):

I would go so far as to say that calling SetRect() or using the default size of a primitive is something most applications will never do.

Yeah, I was just getting it to work in this situation as well. My case was for the form to have a more pop over look rather than it come up full screen over the main application view. So I had the main application view in one page and then added the form in another.

<!-- gh-comment-id:373693014 --> @joegrasse commented on GitHub (Mar 16, 2018): >I would go so far as to say that calling SetRect() or using the default size of a primitive is something most applications will never do. Yeah, I was just getting it to work in this situation as well. My case was for the form to have a more pop over look rather than it come up full screen over the main application view. So I had the main application view in one page and then added the form in another.
Author
Owner

@rivo commented on GitHub (Mar 16, 2018):

Ah, so you would like to set the form to a fixed size at first but it should become smaller automatically if that size exceeds the available screen space. Would something like that help you?

<!-- gh-comment-id:373696384 --> @rivo commented on GitHub (Mar 16, 2018): Ah, so you would like to set the form to a fixed size at first but it should become smaller automatically if that size exceeds the available screen space. Would something like that help you?
Author
Owner

@joegrasse commented on GitHub (Mar 16, 2018):

Yes :)

<!-- gh-comment-id:373696832 --> @joegrasse commented on GitHub (Mar 16, 2018): Yes :)
Author
Owner

@rivo commented on GitHub (Mar 16, 2018):

Let me think about this.

<!-- gh-comment-id:373706344 --> @rivo commented on GitHub (Mar 16, 2018): Let me think about this.
Author
Owner

@rivo commented on GitHub (Mar 23, 2018):

I just added some code to Box that will ensure that the box contents remain within the screen. I think this should help you achieve what you would like to do. Please have a look and let me know if this works for you.

<!-- gh-comment-id:375784632 --> @rivo commented on GitHub (Mar 23, 2018): I just added some code to `Box` that will ensure that the box contents remain within the screen. I think this should help you achieve what you would like to do. Please have a look and let me know if this works for you.
Author
Owner

@joegrasse commented on GitHub (Mar 27, 2018):

@rivo Just so I make sure we are on the same page, The form outline still goes past the terminal screen (which is what I would want), but I can now tab between form items and it focuses as expected. Is this the expected result?

<!-- gh-comment-id:376603712 --> @joegrasse commented on GitHub (Mar 27, 2018): @rivo Just so I make sure we are on the same page, The form outline still goes past the terminal screen (which is what I would want), but I can now tab between form items and it focuses as expected. Is this the expected result?
Author
Owner

@rivo commented on GitHub (Mar 28, 2018):

Every primitive has an "outer" position and size (this is what you see when the border gets drawn) and an "inner" position and size (this is the space where the primitive's content is drawn). The functions are GetRect() and GetInnerRect(), respectively.

I modified GetInnerRect() such that it is always fully contained in the screen. So if your form is larger than the screen, it is expected that while the border still looks like it extends beyond the screen, the form elements will scroll with the focus.

If you don't see this behaviour, let me know.

<!-- gh-comment-id:376937659 --> @rivo commented on GitHub (Mar 28, 2018): Every primitive has an "outer" position and size (this is what you see when the border gets drawn) and an "inner" position and size (this is the space where the primitive's content is drawn). The functions are [`GetRect()`](https://godoc.org/github.com/rivo/tview#Box.GetRect) and [`GetInnerRect()`](https://godoc.org/github.com/rivo/tview#Box.GetInnerRect), respectively. I modified `GetInnerRect()` such that it is always fully contained in the screen. So if your form is larger than the screen, it is expected that while the border still looks like it extends beyond the screen, the form elements will scroll with the focus. If you don't see this behaviour, let me know.
Author
Owner

@joegrasse commented on GitHub (Mar 29, 2018):

It is working as you described.

Thank you.

<!-- gh-comment-id:377217503 --> @joegrasse commented on GitHub (Mar 29, 2018): It is working as you described. Thank you.
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#59
No description provided.