mirror of
https://github.com/rivo/tview.git
synced 2026-04-26 21:35:54 +03:00
[GH-ISSUE #192] Disabling and hiding form fields #150
Labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/tview#150
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @dimonomid on GitHub (Nov 23, 2018).
Original GitHub issue: https://github.com/rivo/tview/issues/192
First of all, thanks a lot for your work on tview, I'm using it in a small project and so far it works quite well. There are just a few missing pieces, one of which is: disabling and hiding form fields. E.g. depending on the other values of the form, it often makes sense to disable/enable some input fields, or even hide/show them.
I tried to mimic it by setting a different background color for the field I want to disable, but that didn't work either because the
Formcomponent overrides it by callingSetFormAttributesfor all components. So far I just set text ton/aand use acceptance function which stops accepting any values when the field should be disabled, but that's far from perfect anyway: the field should change its appearance to make it clear that it's disabled, and should't receive focus.Do you think you'd be open to implementing that?
@rivo commented on GitHub (Nov 26, 2018):
There is
RemoveFormItem()which allows you to remove a form item. But, granted, it's not the same as "hiding" it as you will have to reinsert it somehow.And you are correct, there is no way to disable a form item. I'm not even sure what's a good way to make a field look like it's disabled - and it will have to work for all field types as well, i.e. input fields, checkboxes, drop-downs, and buttons. Currently,
tview's default colour scheme only uses primary colours as more may not be available on some systems. So it's a bit more difficult to make it work well using colours.But I understand your use case. I'm certainly open to adding it. (As my time is limited, please don't expect this to happen immediately.)
If you have any ideas on how to display disabled form items so it's clear to the user that they are disabled, let me know.
@rivo commented on GitHub (Dec 3, 2018):
Any thoughts?
@dimonomid commented on GitHub (Dec 3, 2018):
Hi @rivo , yeah sorry for not replying earlier, I was hoping to actually implement something myself and then show to you.
I think just using the gray font on a black background would make it clear that the field is disabled. But I'd have to try it out first, and play with the colors.
@rivo commented on GitHub (Dec 3, 2018):
Keep in mind that some terminals have very few colours like white, red, yellow, blue, green, cyan, magenta. My own terminal does not diplay "gray".
@dimonomid commented on GitHub (Dec 3, 2018):
Good point, I guess we'd have to stick to just white on black, and with dashes displayed instead of the value. So e.g. while the field is enabled, it displays white
0.0on blue background (as it does now), and when it's disabled, it just displays white---on black background, and isn't focusable.@rivo commented on GitHub (Dec 3, 2018):
I'm sure some users would like to see the field's value even if it is disabled. Maybe wrapping the label in brackets
(and)helps? I haven't tried it out yet so I don't know what it looks like. Just an idea.I'm also not sure if brackets are safe in non-Western languages. (Probably not.)
@dimonomid commented on GitHub (Dec 3, 2018):
I still think that it's certainly useful in some cases to just mask the value to avoid confusion (some might be thinking that the value has some effect while it does not); I think it's easy to make it customizable.
@berrange commented on GitHub (May 27, 2020):
Based on experimentation in my own application that is using tview, I think it is sufficient to just re-use the form item label colour for the text when the item is read-only. Currently the default settings mean the label is yellow on black, and the form field is white on blue. Re-using the label color for read-only fields results in yellow on blue. This is reasonably subtle so that the form items don't look unpleasant when read-only, but still shows the difference for read-only controls in a simple manner.
@gdamore commented on GitHub (May 20, 2021):
Colors are the best way to handle this -- this could be handled via theming as additional options to the style.
I recommend using grays for the disabled field -- basically you could use tcell.ColorSilver as the background and tcell.ColorGray as the foreground.
@gdamore commented on GitHub (May 28, 2021):
I had a similar need. But I wanted to just remove the irrelevant items.
What I wound up doing was subclassing Form and FormItem, and adding Hide() and Show() to my subclassed FormItem. Then my custom From looks for them -- I do this a bit klunky via a Rebuild() method I created that removes all the items, and then adds the ones that aren't hidden back in. A better solution would probably involve changing Draw to skip over those items.
A similar solution is possible for the buttons.
@mail2lawi commented on GitHub (Nov 24, 2022):
I think another approach would be to "lock" the fields that should are to be disabled.
Maybe I'm missing something but I don't feel like disabling a field just by changing it's colour properties is sufficient. An operator can still type in text in the text area, for instance.
There should be a method to restrict input/amendment on the field but still allow it to be displayed. If such a feature exists let me know. I can't seem to find one
@rivo commented on GitHub (Mar 20, 2023):
I know this took a long time but form elements can now be disabled. Disabled elements will look like text, with a black background instead of a blue background. They will also be skipped during navigation and will not handle any keyboard or mouse input.
A form must have at least one enabled item, however (button or otherwise).
@atzub commented on GitHub (Jul 10, 2023):
Thanks rivo, you are the best :)