Switchy Client Management Screen

[HestiMae]

Closes #25 What's done:

• Layout of preset management and module management tabs
• Tab switcher
• Client-side method calls on SwitchyDisplayablePresets object

To-do:

• [x] Layout of data tab (covers importing and exporting)
• [x] Interface for refreshing screens using display presets
• [x] Button on quick switcher to access management screen
• [x] Refresh interface implementation for quick switcher and management screen
• [x] Use client API to send actions to the server
• [x] Lock screen after sending action until refresh

[sisby-folk]

Looking really good so far! I'll give this a more thorough review when you're happy with it

https://user-images.githubusercontent.com/55819817/222342767-7374ad01-3dbe-4e0c-a214-80e340984266.mp4

[HestiMae]

Screen is now functionally complete! it could use some clean up, but I'm happy to merge this and then start up a cleanup PR for post-2.0 as there's no API in this thing.

Here are a few screenshots - I'd still like to clean this up both technically and UX-wise, but it's still got an intuitive flow.

[sisby-folk]

Super intense work! nice job getting it all hooked up and functional.

We've given this a play around and have a few of points of improvement - but we'd like those to be optionally addressed later down the track (we'll take a crack at it if you dont) as we really want to smash UI stuff out into another submodule and get 2.0 out the door ASAP.

• Visually I'd like more surface variety to break up some of the more complex areas.
  • I think the "enabled disabled" module areas could be darkened so that they're "inset" into the panel.
  • Horizontal line items like modules and presets (and their buttons) could have a similar colour-change to more clearly show them as being "items"
• Being able to rename/create multiple presets at once is no good, and it makes the behaviour of the cancel/confirm buttons strange. Limiting it to just one makes sense based on mobile UI i'm used to.
• Reusing the module info and confirmation text for the confirmation dialog boxes is really good, but ideally we'd like to show the feedback that's coming up in the chat on the screen instead (as a toast) - I think this will tie directly into plans we have for identifying individual requests.
  • Just to quickly explain - Client API requests will gain an optional callback parameter that will be given the returned displayPresets alongside some kind of feedback object with an enum type and message text - you'll be able to use this for toasts. I'll do my best to adapt the screen interface to use this in some way.