EFForg / EFForg/rayhunter

add a device connection screen to the GUI installer

Open
#1,137 4 comments 0 reactions 0 assignees View on GitHub
documentation help wanted javascript ui
Dominant language
Rust
Stars
5.8k
Forks
490
Avg merge
3d 10h
Merged PRs (30d)
23

Description

EDIT: after the discussion below, i've rewritten this post to suggest a new design

in the [GUI installer](https://github.com/EFForg/rayhunter/tree/main/installer-gui), the user currently isn't shown any instructions on how to connect their device to their computer. i think we should fix this so the user doesn't have to hop back and forth between the GUI and our docs

i agree with untitaker that we should prioritize doing this for the [recommended devices](https://efforg.github.io/rayhunter/supported-devices.html#1-recommended-devices) for now. here's how i'd accomplish this, but people are welcome to propose their own design

### background

the subcommands `orbic` and `tplink` (which are our recommended devices) as well as `moxee`, `tmobile`, and `wingtech` all connect to the device over the network either thru wifi or usb tethering (if the device supports it and usb tethering is enabled)

### backend

i'd add a boolean to both [SubcommandModifier](https://github.com/EFForg/rayhunter/blob/b0468a7331f1abb03afedc634cce6b56d5db1331/installer-gui/src-tauri/src/modifiers.rs#L24) and [Subcommand](https://github.com/EFForg/rayhunter/blob/b0468a7331f1abb03afedc634cce6b56d5db1331/installer-gui/src-tauri/src/introspect.rs#L53) named something like `show_device_network_setup`. i'd set this to `true` for the SubcommandModifiers i listed above and `false` for everything else

### frontend

i'd add a matching boolean to the [InstallerSubcommand](https://github.com/EFForg/rayhunter/blob/b0468a7331f1abb03afedc634cce6b56d5db1331/installer-gui/src/lib/types.svelte.ts#L10) type. then in [+page.svelte](https://github.com/EFForg/rayhunter/blob/b0468a7331f1abb03afedc634cce6b56d5db1331/installer-gui/src/routes/%2Bpage.svelte) i'd add a new screen between `DeviceSelection` and `ArgSelection` screen named something like `DeviceConnect` that is only shown if `show_device_networking_setup` is true

this would probably make use of a new svelte component that i'd create in [lib](https://github.com/EFForg/rayhunter/tree/b0468a7331f1abb03afedc634cce6b56d5db1331/installer-gui/src/lib) like the other components. this component would have a couple buttons to either go back to device selection or continue onto arg selection as well as display instructions similar to [this](https://github.com/EFForg/rayhunter/blob/b869b81bcf7c3bec73f0328af4742fdf3565d2b8/doc/installing-from-release.md?plain=1#L25-L33) altho i'd change the last sentence to something like

> You know you are in the right network when you can access the hardware's admin menu at the device specific IP address ( for Orbic or for TP-Link).

i'd advise against getting fancy in the initial version of this and probably just always use a static string like this

in the long run i think we could move consider moving this screen after `ArgSelection` and make use of provided arguments and the default value for `admin_ip` to build a specific instructions for the user's case. i think that doing this well in a way that is resistant to bugs as things change over time is a little tricky and requires some refactoring so i didn't take the time to write up how i'd do that. i personally think that even this simple version gets us most of the benefit here

Contributor guide

Open the contributing guide

Research direction

Start with installer-gui/src-tauri/src/modifiers.rs and introspect.rs, then trace the matching type in installer-gui/src/lib/types.svelte.ts and the flow in installer-gui/src/routes/+page.svelte. Add the device-connection step for the specified subcommands, using a component under installer-gui/src/lib, with navigation between device selection and argument selection. Done means the screen appears only for the intended devices and displays the connection instructions.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust, typescript
Domain
backend, desktop, frontend
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Clearly specified
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.