liamwarfield
ff14f577fe
I did some more thinking about the whole trait/boundary stuff and reallized that we don't need the GUI to handle the generic-ness of a trait object since only 1 platform will ever be used in a binary. What do you think of the following:
1. Define a platform trait
2. Each platform defines a zero-sized struct implementing the trait (ex `WebPlatform`).
3. Create an ifdef'd type alias on those structs:
```
// gui/src/platform/mod.rs
#[cfg(feature = "web")]
pub type CurrentPlatform = web::WebPlatform;
#[cfg(feature = "desktop")]
pub type CurrentPlatform = desktop::DesktopPlatform;
#[cfg(feature = "mobile")]
pub type CurrentPlatform = mobile::MobilePlatform;
```
4. Add a compile time assertion that `CurrentPlatform` implements `Platform`.
Pros:
- We don't end up working around async trait objects
- We define what functions are needed for a platform
- We save a little on binary size by avoiding a fully generic solution.
Cons:
- The trait does not really do much other than being a collection of functions.
- In some ways it seems like what we're currently doing but with extra steps.
GUI Development
Running Desktop
cargo install dioxus-cli --version 0.7.1dx run -p mumble-web2-gui --platform desktop --release
Running Web (development)
cargo install dioxus-cli --version 0.7.1dx serve -p mumble-web2-gui --platform webcd docker && docker compose up- connect to
https://localhost:64444 - fill in the proxy url as
https://127.0.0.1:4433/proxy(this should autofill)
Running Web (with proxy only)
cargo install dioxus-cli --version 0.7.1dx build -p mumble-web2-gui --platform web --releasecp config.toml.example config.tomlcargo run -p mumble-web2-proxyin the background- connect to
localhost:8080