← All Workshops

MudEngine Part 10: Desktop with Blitz

Step 6 / 12

Configure the window

By default, the Blitz window opens at a reasonable size. You can customise it with dioxus_native::Config and dioxus_native::WindowAttributes.

This is optional — the MUD works fine with default settings. But it's useful to know how to control the window for a polished desktop feel.

To set a custom window title and size, add this before the launch call:

mud-engine/src/main.rs
use dioxus_native::{Config, WindowAttributes, LogicalSize};

fn main() {
    #[cfg(not(feature = "server"))]
    set_server_url("http://localhost:8080");

    #[cfg(not(feature = "server"))]
    {
        let cfg = Config::new()
            .with_window_attributes(
                WindowAttributes::new()
                    .with_title("MudEngine")
                    .with_inner_size(LogicalSize::new(1024.0, 768.0)),
            );
        dioxus_native::launch_cfg(App, cfg);
    }

    #[cfg(feature = "server")]
    dioxus::launch(App);
}
🎯 The cfg split

Note the #[cfg(feature = "server")] split above. This is needed because:

  1. Server binary — compiled with features = ["server"]. It uses dioxus::launch(App) to render HTML on the server side.
  2. Client binary — compiled without the server feature. It uses dioxus_native::launch_cfg(App, cfg) with the native renderer.

If you don't split these, the server will try to open a native window — which won't work on a headless deployment.

A simpler approach for this workshop is to just use dioxus_native::launch unconditionally and accept that the server binary won't have a UI (which is fine — the server runs headless and serves WebSocket connections):

mud-engine/src/main.rs
fn main() {
    #[cfg(not(feature = "server"))]
    set_server_url("http://localhost:8080");

    // This call works on the client.
    // On the server, this binary path isn't used
    // (the server is launched via dx serve).
    dioxus_native::launch(App);
}
💡 Why this works

When you run dx serve, it compiles two binaries: the server (with server feature) and a client WASM bundle (with web feature). The server binary uses dioxus::launch (from its own code path), so calling dioxus_native::launch in the shared main.rs is fine — it's only compiled when you run cargo run without the server feature.

In other words: dx serve controls the server via its own entry point. Your main.rs is the client entry point.

Step 6 / 12