[GH-ISSUE #609] Feature request: text in forms

kerem commented

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

Owner

Originally created by @SamWhited on GitHub (May 27, 2021).
Original GitHub issue: https://github.com/rivo/tview/issues/609

I would like the ability to provide instructions in forms by drawing text. This could be by allowing some sort of "empty" FormItem that is only a label, or by allowing TextView's in forms (with no label) and making minor modification to the height calculation to accommodate multi-line text.

I have already done both while experimenting but wanted to check with you whether you'd accept a PR for this before submitting one or the other; maybe there's a better way that I'm not thinking or it doesn't fit in the concept of a form for other reasons.

Thanks!

Originally created by @SamWhited on GitHub (May 27, 2021). Original GitHub issue: https://github.com/rivo/tview/issues/609 I would like the ability to provide instructions in forms by drawing text. This could be by allowing some sort of "empty" `FormItem` that is only a label, or by allowing `TextView`'s in forms (with no label) and making minor modification to the height calculation to accommodate multi-line text. I have already done both while experimenting but wanted to check with you whether you'd accept a PR for this before submitting one or the other; maybe there's a better way that I'm not thinking or it doesn't fit in the concept of a form for other reasons. Thanks!

kerem closed this issue

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

kerem commented

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

Author

Owner

@rivo commented on GitHub (Jun 1, 2021):

Currently, all form items have a label and a "field" (e.g. an input field). Labels are aligned, at least in the vertical version of the form.

If there was an item that is only a label, it would appear only in the label column (although one could include a text-only field as well but it would only span one line).

If you allowed a TextView without a label, it would only appear in the field column. Or there could be a form version which also includes a label. But label and text would still be separate.

None of these would span both columns. But I suppose this is not a requirement of yours?

@rivo commented on GitHub (Jun 1, 2021): Currently, all form items have a label and a "field" (e.g. an input field). Labels are aligned, at least in the vertical version of the form. If there was an item that is only a label, it would appear only in the label column (although one could include a text-only field as well but it would only span one line). If you allowed a `TextView` without a label, it would only appear in the field column. Or there could be a form version which also includes a label. But label and text would still be separate. None of these would span both columns. But I suppose this is not a requirement of yours?

kerem commented

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

Author

Owner

@SamWhited commented on GitHub (Jun 1, 2021):

I've done two implementations, the TextView one I added an interface to let form elements indicate that they want to span multiple lines. The other, simpler one, I called a "label" but I ended up making it always return the empty string for the label and then print text in the other field spanning both lines. Here is a screenshot of that one:

@SamWhited commented on GitHub (Jun 1, 2021): I've done two implementations, the TextView one I added an interface to let form elements indicate that they want to span multiple lines. The other, simpler one, I called a "label" but I ended up making it always return the empty string for the label and then print text in the other field spanning both lines. Here is a screenshot of that one: ![A form with a text explanation of its use above the first form field](https://user-images.githubusercontent.com/512573/120314091-634b6580-c2ca-11eb-875f-dfcadd4073d4.png)

kerem commented

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

Author

Owner

@SamWhited commented on GitHub (Jun 1, 2021):

And here's a shot of a textview taking up multiple lines in the form:

@SamWhited commented on GitHub (Jun 1, 2021): And here's a shot of a textview taking up multiple lines in the form: ![Form showing multiple lines of text at the top](https://user-images.githubusercontent.com/512573/120318579-8c222980-c2cf-11eb-8d47-5959a2826d72.png)

kerem commented

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

Author

Owner

@rivo commented on GitHub (Jun 1, 2021):

then print text in the other field spanning both lines

You mean both "columns"?

Rather than talking about actual implementations, I'd like to talk about requirements in your application(s). In your screenshots, you don't follow the separation between label and field. It looks to me like what you needed was a header text. This could have been done with Flex, Grid, or Frame.

At first, I had two other use cases in mind: read-only text fields and item group headers. Read-only text fields could even be done with an InputField already (by rejecting all input). Item group headers would be something like "Credit card Information", then "Billing Address", then "Confirm", with various form items underneath them. These would definitely span both the label and field columns. It would be great if anybody with this requirement could chime in (maybe with an example).

making minor modification to the height calculation to accommodate multi-line text.

Do you require the height of the TextView to be known in advance? Or do you somehow calculate the resulting height first? Also, how do you lay out text views in horizontal forms?

@rivo commented on GitHub (Jun 1, 2021): > then print text in the other field spanning both lines You mean both "columns"? Rather than talking about actual implementations, I'd like to talk about requirements in your application(s). In your screenshots, you don't follow the separation between label and field. It looks to me like what you needed was a header text. This could have been done with `Flex`, `Grid`, or `Frame`. At first, I had two other use cases in mind: read-only text fields and item group headers. Read-only text fields could even be done with an `InputField` already (by rejecting all input). Item group headers would be something like "Credit card Information", then "Billing Address", then "Confirm", with various form items underneath them. These would definitely span both the label and field columns. It would be great if anybody with this requirement could chime in (maybe with an example). > making minor modification to the height calculation to accommodate multi-line text. Do you require the height of the `TextView` to be known in advance? Or do you somehow calculate the resulting height first? Also, how do you lay out text views in horizontal forms?

kerem commented

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

Author

Owner

@SamWhited commented on GitHub (Jun 1, 2021):

In those particular examples the text is at the top, but the forms are being converted from forms in a different system and could have appeared anywhere in the form (so I can't just use a different layout or I'd have to split the form into multiple ones so that I can put text between two forms, then the default buttons and what not wouldn't work if you weren't in the part of the form with the buttons).

I think I tried with an input field originally, but I can't remember what was wrong. I might have just been frustrated applying different styling to make it look like text and not like an input field.

With regards to the textview I was just calculating the number of lines to get the "height". This does not play well with wrapping yet and really needs to use the same algorithm. I didn't try it in horizontal forms. This would all require more work but I didn't want to do to much beyond a proof of concept because I didn't know if you'd want either idea.

EDIT: yes, I tried again with an inputfield and it's just a bit of a pain. The defaults are different so you have to figure out how to reset eg. the background and text color, then you still have a blinking cursor and the field is selectable so you have to add a handler to skip over it in the tab order and what not, etc. it was easier just to make a new type based on a box that draws text inside of itself.

@SamWhited commented on GitHub (Jun 1, 2021): In those particular examples the text is at the top, but the forms are being converted from forms in a different system and could have appeared anywhere in the form (so I can't just use a different layout or I'd have to split the form into multiple ones so that I can put text between two forms, then the default buttons and what not wouldn't work if you weren't in the part of the form with the buttons). I think I tried with an input field originally, but I can't remember what was wrong. I might have just been frustrated applying different styling to make it look like text and not like an input field. With regards to the textview I was just calculating the number of lines to get the "height". This does not play well with wrapping yet and really needs to use the same algorithm. I didn't try it in horizontal forms. This would all require more work but I didn't want to do to much beyond a proof of concept because I didn't know if you'd want either idea. *EDIT:* yes, I tried again with an inputfield and it's just a bit of a pain. The defaults are different so you have to figure out how to reset eg. the background and text color, then you still have a blinking cursor and the field is selectable so you have to add a handler to skip over it in the tab order and what not, etc. it was easier just to make a new type based on a box that draws text inside of itself.

kerem commented

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

Author

Owner

@rivo commented on GitHub (Jun 1, 2021):

This would all require more work but I didn't want to do to much beyond a proof of concept because I didn't know if you'd want either idea.

That's totally fine. I'm asking these questions to understand what's being asked. It'll probably be my own implementation anyway.

But generally, I understand that you will need something that spans across label and field, correct? (The InputField idea would not provide that.)

I think it will be a TextView in the form. But as it stands now, the height will have to be pre-determined by you. There's no code in tview that allows size information to bubble up.

@rivo commented on GitHub (Jun 1, 2021): > This would all require more work but I didn't want to do to much beyond a proof of concept because I didn't know if you'd want either idea. That's totally fine. I'm asking these questions to understand what's being asked. It'll probably be my own implementation anyway. But generally, I understand that you will need something that spans across label and field, correct? (The `InputField` idea would not provide that.) I think it will be a `TextView` in the form. But as it stands now, the height will have to be pre-determined by you. There's no code in `tview` that allows size information to bubble up.

kerem commented

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

Author

Owner

@SamWhited commented on GitHub (Jun 1, 2021):

But generally, I understand that you will need something that spans across label and field, correct?

Not necessarily, I just need something that lets me provide instructions or other notes in the form. Spanning the label and field columns just looked best IMO, but it's not a requirement of mine at least.

There's no code in tview that allows size information to bubble up.

Yes, I had to implement this code in my proof of concept.

@SamWhited commented on GitHub (Jun 1, 2021): > But generally, I understand that you will need something that spans across label and field, correct? Not necessarily, I just need something that lets me provide instructions or other notes in the form. Spanning the label and field columns just looked best IMO, but it's not a requirement of mine at least. > There's no code in tview that allows size information to bubble up. Yes, I had to implement this code in my proof of concept.

kerem commented

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

Author

Owner

@rivo commented on GitHub (Dec 10, 2022):

The latest commit (3f246bd) makes it possible to add a TextView to a Form.

I believe this should resolve this issue so I'm closing it.

@rivo commented on GitHub (Dec 10, 2022): The latest commit ([3f246bd](https://github.com/rivo/tview/commit/3f246bda869aa291afc4106da82e893568286144)) makes it possible to add a `TextView` to a `Form`. I believe this should resolve this issue so I'm closing it.

kerem referenced this issue

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

[PR #444] [MERGED] Fixed terminal colors #956

Rows
Columns

[GH-ISSUE #609] Feature request: text in forms #445