[GH-ISSUE #33] Support horizontal layout on Form #27

New issue

Closed

opened 2026-03-04 01:01:13 +03:00 by kerem · 4 comments

kerem commented

2026-03-04 01:01:13 +03:00

Owner

Originally created by @triddell on GitHub (Jan 14, 2018).
Original GitHub issue: https://github.com/rivo/tview/issues/33

I have a need for a horizontal layout for a form. My form will only have a few checkboxes and then maybe a button or two. It would be nice from a screen real estate perspective to have this available to be horizontal.

My use case is using my previous request (#32) to dynamically generate the form based on a "command" which is selected from a List. Then a skinny, horizontal form could be placed above a TextView, which is then populated when the "OK" form button is pressed.

I'm grouping commands on various screens (like your presentation demo) and I'd like to be able to have the form dynamic based on what command is selected (and horizontal).

Originally created by @triddell on GitHub (Jan 14, 2018). Original GitHub issue: https://github.com/rivo/tview/issues/33 I have a need for a horizontal layout for a form. My form will only have a few checkboxes and then maybe a button or two. It would be nice from a screen real estate perspective to have this available to be horizontal. My use case is using my previous request (#32) to dynamically generate the form based on a "command" which is selected from a List. Then a skinny, horizontal form could be placed above a TextView, which is then populated when the "OK" form button is pressed. I'm grouping commands on various screens (like your presentation demo) and I'd like to be able to have the form dynamic based on what command is selected (and horizontal).

kerem closed this issue

2026-03-04 01:01:13 +03:00

kerem commented

2026-03-04 01:01:14 +03:00

Author

Owner

@triddell commented on GitHub (Jan 15, 2018):

If these horizontal form changes would be hard, another thought I had was using a modal dialog box. This could potentially fit my use case too but I would need all of the features of a Form in a Modal window. It looks like right now Modals support text and buttons but not fields, etc.

@triddell commented on GitHub (Jan 15, 2018): If these horizontal form changes would be hard, another thought I had was using a modal dialog box. This could potentially fit my use case too but I would need all of the features of a Form in a Modal window. It looks like right now Modals support text and buttons but not fields, etc.

kerem commented

2026-03-04 01:01:14 +03:00

Author

Owner

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

It's ok. I've added a horizontal layout to the Form class. You can now call form.SetHorizontal(true). If there is not enough space, form items will move into the next line.

The Modal class is not really meant to be used as a form. Its primary purpose is to notify the user of something, maybe a warning, confirmation, or error message. It has buttons (e.g. "Save" and "Cancel") so I instead of replicating functionality, I used the Form class to place buttons in the modal. But the modal is not meant to be used as a form.

@rivo commented on GitHub (Jan 16, 2018): It's ok. I've added a horizontal layout to the `Form` class. You can now call `form.SetHorizontal(true)`. If there is not enough space, form items will move into the next line. The `Modal` class is not really meant to be used as a form. Its primary purpose is to notify the user of something, maybe a warning, confirmation, or error message. It has buttons (e.g. "Save" and "Cancel") so I instead of replicating functionality, I used the `Form` class to place buttons in the modal. But the modal is not meant to be used as a form.

kerem commented

2026-03-04 01:01:14 +03:00

Author

Owner

@triddell commented on GitHub (Jan 17, 2018):

Thank you! This is exactly what I needed. One quick question... since my form is now dynamic (I always have three buttons but sometimes I have a field or two in front of those), how to I "reset" the focus to the first field?

For instance, it seems that tview is remembering the index number of the last button that was pressed. Then, when the form is reused with a different number of items, the initial highlighted/selected field or button is this remembered index number.

So, when I set focus on the form, how can I make sure that the focused field is the first field (index=0)? I couldn't find this exposed in the API.

Thanks again for your efforts on this great library!

@triddell commented on GitHub (Jan 17, 2018): Thank you! This is exactly what I needed. One quick question... since my form is now dynamic (I always have three buttons but sometimes I have a field or two in front of those), how to I "reset" the focus to the first field? For instance, it seems that tview is remembering the index number of the last button that was pressed. Then, when the form is reused with a different number of items, the initial highlighted/selected field or button is this remembered index number. So, when I set focus on the form, how can I make sure that the focused field is the first field (index=0)? I couldn't find this exposed in the API. Thanks again for your efforts on this great library!

kerem commented

2026-03-04 01:01:14 +03:00

Author

Owner

@rivo commented on GitHub (Jan 17, 2018):

I actually forgot to reset this in the new Clear() function. The latest commit now resets the focus to the first element.

Since you're using forms a lot, please note that the functions which were previously called ...FieldLength() are now called ...FieldWidth(). With unicode support (especially with wide Asian characters), there is a difference between the number of runes in a string and the width displayed on screen. This should be reflected in the function names and "length" was just not clear enough.

@rivo commented on GitHub (Jan 17, 2018): I actually forgot to reset this in the new `Clear()` function. The latest commit now resets the focus to the first element. Since you're using forms a lot, please note that the functions which were previously called `...FieldLength()` are now called `...FieldWidth()`. With unicode support (especially with wide Asian characters), there is a difference between the number of runes in a string and the width displayed on screen. This should be reflected in the function names and "length" was just not clear enough.

kerem referenced this issue

2026-03-04 01:08:10 +03:00

[PR #29] [MERGED] Added GetSelection() and SetSelectionChangedFunc() to Table #838