EDIT: after the discussion below, i've rewritten this post to suggest a new design
in the GUI installer, 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 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 and Subcommand 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 type. then in +page.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 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 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 (http://192.168.1.1 for Orbic or http://192.168.0.1 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
EDIT: after the discussion below, i've rewritten this post to suggest a new design
in the GUI installer, 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 for now. here's how i'd accomplish this, but people are welcome to propose their own design
background
the subcommands
orbicandtplink(which are our recommended devices) as well asmoxee,tmobile, andwingtechall 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 and Subcommand named something like
show_device_network_setup. i'd set this totruefor the SubcommandModifiers i listed above andfalsefor everything elsefrontend
i'd add a matching boolean to the InstallerSubcommand type. then in +page.svelte i'd add a new screen between
DeviceSelectionandArgSelectionscreen named something likeDeviceConnectthat is only shown ifshow_device_networking_setupis truethis would probably make use of a new svelte component that i'd create in 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 altho i'd change the last sentence to something like
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
ArgSelectionand make use of provided arguments and the default value foradmin_ipto 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