Skip to content

Login Screen Phase 1: UI screen, username + password only #113

@kevinaboos

Description

@kevinaboos

Robrix needs a screen that allows the user to enter their username and password in order to login.

New functionality

  1. A username field. In Makepad, this is a default TextInput widget.
    • in the live DSL, set empty_text to "Enter username..."
  2. a password field. In Makepad, this is a TextInput widget with
    • in the live DSL, set empty_text to "Enter username..."
  3. A homeserver field, which should be pre-filled to "matrix.org" by default.
    • in the live DSL, set empty_text to "Homeserver address"

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:

robrix/src/sliding_sync.rs

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

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

Status

Done

Relationships

None yet

Development

No branches or pull requests

Issue actions