You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Break up the widgets into separate structs. Right now all the widgets are this one giant widget
template. Instead, if you take a look at the current UI there's:
- background
- clock widget
- reboot buttons
- login form:
- welcome message
- either:
session selection:
- user field
- session field
- goto auth buttonauth:
- selected user (const)
- why no selected session? (const)
- password field
- auth button
And some of these components are the same thing, just different labels, So there's not gonna be a
separate type for each element.
Encode the state (session/auth screen, selected users) as a data structure and use it to render
the ui.
Move the business logic (greetd interface) into a trait and instead of doing if demo { Make a DemoGreeter. 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):
Break up the UI into smaller components
Use state to render the UI in update().
These 2 might be too tightly coupled to separate tho...
The text was updated successfully, but these errors were encountered:
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.
Here are the changes I propose:
template. Instead, if you take a look at the current UI there's:
separate type for each element.
the ui.
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...
The text was updated successfully, but these errors were encountered: