Open max-ishere opened 3 months ago
Okie... I have made a widget that replicates (good enough) the behavior of the user/session input widget. It works like this: you give it options and initial state (which can even be the freeform manual input thing) and it sends Output messages with what the user has typed/clicked from list. The widget works by itself, but I anticipate it being a challange to integrate into the current app.
These are the images of the most bare bones implementation that I made, you can see there's no styling, gaps, the toggle button is in the wrong state, it will be more polished in the PR.
This window has a box: left: input widget, right: what the root thinks the widget state is (text after the toggle button).
The input widget can be customized: label text, manual input placeholder (gray text) and the list of options, initial state.
It emits events with what is selected, either index of the current option in the list (number) or the string in the text field, whichever the user sees.
I think this will make the code a little cleaner and easier to work with
Here are the changes I propose:
And some of these components are the same thing, just different labels, So there's not gonna be a separate type for each element.
if demo {
Make aDemoGreeter
. Btw this demo greeter can respond with "Demo mode password: pass".And this way the UI can be tested too by simply setting up the UI state struct, running the update() method and asserting the updated ui state.
I can do the refactoring work and PR it in as small of increments as is managable for review. The steps would probably be as such (not sure about the order):
update()
. These 2 might be too tightly coupled to separate tho...