-
Notifications
You must be signed in to change notification settings - Fork 41
Description
Robrix needs a screen that allows the user to enter their username and password in order to login.
New functionality
- A username field. In Makepad, this is a default
TextInputwidget.- in the live DSL, set
empty_textto "Enter username..."
- in the live DSL, set
- a password field. In Makepad, this is a
TextInputwidget with- in the live DSL, set
empty_textto "Enter username..."
- in the live DSL, set
- A homeserver field, which should be pre-filled to "matrix.org" by default.
- in the live DSL, set
empty_textto "Homeserver address"
- in the live DSL, set
The username should support either a full Matrix UserId, e.g., "me@matrix.org", as well as a partial UserId localpart without the "@serverdomain.*" suffix.
If the homeserver address field is provided, then that should be used as the server domain for the username field (if only a partial UserId is provided).
Note that Robrix currently requires the homeserver to support sliding sync, so if the user overrides the default "matrix.org" homeserver field, we should show a warning Label beneath the homeserver TextInput field that mentions this limitation.
Interaction with CLI arguments
If command-line arguments are provided, then the values provided on the command line should be pre-filled into the text fields of the above 3 TextInput widgets.
Creating a separate UI screen
Makepad currently doesn't have a built-in way to show an ordered series of separate screens, e.g., like how Android apps can navigate through a series of different Activities.
To get around this problem, @guofoo had the clever idea of re-using the Profile screen (the bottom right tab of Robrix) to display a new login pane if the user is not already logged in. Then, if they are logged in, that Profile view can just be used to display content about their profile -- the username, avatar, ignore list, current device name, etc. But that can be saved as part of a future issue about fetching and displaying info about the current logged-in user.
Re-using existing login code
The existing login code is here:
Lines 79 to 106 in 106033d
| // Query the server for supported login types. | |
| let login_kinds = client.matrix_auth().get_login_types().await?; | |
| if !login_kinds.flows.iter().any(|flow| matches!(flow, LoginType::Password(_))) { | |
| bail!("Server does not support username + password login flow."); | |
| } | |
| // Attempt to login using the CLI-provided username & password. | |
| let login_result = client | |
| .matrix_auth() | |
| .login_username(&cli.username, &cli.password) | |
| .initial_device_display_name("robrix-un-pw") | |
| .send() | |
| .await?; | |
| log!("Login result: {login_result:?}"); | |
| if client.logged_in() { | |
| log!("Logged in successfully? {:?}", client.logged_in()); | |
| enqueue_rooms_list_update(RoomsListUpdate::Status { | |
| status: format!("Logged in as {}. Loading rooms...", &cli.username), | |
| }); | |
| Ok((client, _token)) | |
| } else { | |
| enqueue_rooms_list_update(RoomsListUpdate::Status { | |
| status: format!("Failed to login as {}: {:?}", &cli.username, login_result), | |
| }); | |
| bail!("Failed to login as {}: {login_result:?}", &cli.username) | |
| } |
It should be straightforward to refactor this into a separate function and then invoke it with values obtained from the above 3 TextInput fields.
Note about persistence
Lightly depends on (and is related to) issue #112 about app data persistence. This is noteworthy because we will eventually want to save the user's login session to persistent storage such that they don't have to re-enter their credie
Metadata
Metadata
Labels
Type
Projects
Status