Add text input widget

[caeyo]

Adds a widget allowing text input from the user.

Related PRs to enable this functionality across the ecosystem:

• Add text input widget support asr#136
• Add text input widget support LiveSplit.AutoSplittingRuntime#26
• Add text input widget support asr-debugger#27

[CryZe]

Is there any particular use case you have in mind for, like an actual auto splitter that exists, or that you want to write, where you would want to use this? Because generally speaking, I would rather prefer for us to identify actual use cases instead of just adding APIs just because we can. Of course, this is useful. There is no question about it. But I think if we consider actual use cases, then we can identify potentially even better ways of expressing them. We had this before with the file inputs, where we also just wanted to add text inputs until we realized, it would be better to express that as an actual file input. And then someone else recently suggested that they would want to use text inputs, so the users can put in the name of segments, so the auto splitter knows about which segment to split for. But even for that, it would probably be better to have an actual combo box that shows segment names instead of just a text box. So I want to discuss this first. If you have an actual use case in mind, maybe it can be expressed better before we just add something general that isn't as well suited.

[AlexKnauth]

One use case I've had people ask about, is for an auto-split to trigger on entering or exiting a certain Scene Name

[CryZe]

One use case I've had people ask about, is for an auto-split to trigger on entering or exiting a certain Scene Name

Don't most games just have fixed scene names or so and you can just express them through the combo box support that we have rather than a freeform text input where you can easily put in the wrong name?

[AlexKnauth]

And while a combo box with an option for every scene name that people might want in the vanilla game can work for the vanilla game, that can't possibly cover every scene name that exists in modded content, which I've heard Celeste speedrunners are very interested in in particular, and some Hollow Knight speedrunners have been interested in as well, though to a lesser extent than Celeste

[CryZe]

To me that sounds like it should maybe be an addition to the choice API instead where you add your fixed choices but then call user_settings_make_choice_freeform or so. So the users still have all the existing scenes to choose from, but have a text based combo box where they can edit the actual text to whatever they want (or in other words turn it from a drop down widget into a combo box widget)

[AlexKnauth]

I think it would be easier on the implementation side of the multiple front-ends, such as LiveSplit.AutoSplittingRuntime, asr-debugger, auto-splitting-ide, obs-livesplit-one, livesplit-one-druid, and whatever additional timer program you're working on, if drop-downs and text inputs are separate widgets that each only do their one thing well. There are places in those widgets where they translate between strings and indexes that would have to be reworked, and I don't know what the state of truly freeform combo-box widgets is for all of the GUI frameworks involved

[CryZe]

I honestly don't think that's that big of a deal. If a particular frontend can't display a proper combo box with a text input, then it can just do a normal text input. Like the idea is really just to have additional suggestions for the choice. But if your UI can't display that, then just display it as a text box. I think it's still better to have the ability to provide the choices than just fully give up essentially because some user interfaces might not be able to visualize it.

[AlexKnauth]

Hm, that's possible, it could make sense if we have a way of telling the front-end that it really is definitely freeform like user_settings_make_choice_freeform or OBS's OBS_COMBO_TYPE_EDITABLE

[caeyo]

I’m the one who recently suggested text input in the Discord where I already had this conversation with Alex, but I’ll repeat myself here

The application is for Celeste, I have rewritten the existing autosplitter to be cross platform/sandboxed with the new runtime as there has been demand for it (there already exist at least 3 alternatives for Linux, but none are designed to be unified). Because the splitter already exists and is for one of the most popular speedgames, the community has a split workflow they are used to, and to justify replacement I am attempting to replicate that as best I can (without the access to winforms that the current splitter uses) to minimise friction.

I think it’s been addressed that arbitrary string input is necessary (I need to handle speedrunning of modded levels), so I will address why a combo box with text input is worse UI than a pure text box.

Runners like to split on individual levels (same concept as scenes), and there are 799 levels in vanilla Celeste. I’m of the view (and I am not alone from discussion with the Celeste community) that it is a waste of time to present users with a 799 count dropdown. Celeste’s internal level names have no consistent pattern to them and are sometimes shared across separate chapters of the game, so for a dropdown to provide useful information I would need human readable names to distinguish “Chapter 1 Level 1” - except paths through a chapter also vary based on category and skill level, so numbered ordering is impossible. At that point I would revert back to using Celeste’s internal level names as the dropdown description, but in order for a runner to find the level they’re looking for they would need to go to the game and determine the level name string - and at that point they already have the text they want, so they are most likely to just input it and bypass scrolling through the dropdown entirely.

The essence of this long winded explanation is that a dropdown here provides zero value because the most accessible workflow defaults to inputting text over searching for and selecting any choice. I also would argue that it is actively creating negative value because a 799 count dropdown is absurdly long and obtrusive - that is a stylistic argument so it holds less weight, but there is also validity to the notion that livesplit should give autosplitter devs stylistic control.

If you would like to add an editable dropdown then by all means, I can see the use case for it, I just don’t believe it is useful for my case and would appreciate having simple text input instead. This is a blocker for porting the Celeste splitter, so if you decide to close it then I will drop the project or explore alternatives

[CryZe]

Alright, that's good enough justification for me. Although I'm at least a little bit worried that this might just be used for basically everything in the future, that people aren't going to request more specialized APIs like a number input or a segment input or something like that, even though those might be better suited. But because it's a general-purpose text box, they might just always use that. I'm a little bit worried about that. But otherwise, your justification makes sense to me, so I'm going to merge this once the CI is green.