Trait AppSettingsExt 

pub trait AppSettingsExt {
    // Required methods
    fn add_setting<T: Resource + DeserializeOwned + Default>(
        &mut self,
        section: &str,
    ) -> &mut Self;
    fn add_project_setting<T: Resource + DeserializeOwned + Default>(
        &mut self,
        section: &str,
    ) -> &mut Self;
}

Reading settings while the app is built.

Required Methods

fn add_setting<T: Resource + DeserializeOwned + Default>( &mut self, section: &str, ) -> &mut Self

Inserts T from the [section] table of the Settings, read from RIG_HOME/settings.toml the first time (unless the app inserted some, as a test does). A table that does not read as T inserts T::default() and is one of Settings::problems.

fn add_project_setting<T: Resource + DeserializeOwned + Default>( &mut self, section: &str, ) -> &mut Self

As add_setting, then, when the app starts (PreStartup), the same table of the project’s .rig/settings.toml, read through the ProjectWorkspace under the ProjectRoot, merged key by key over the user’s: so read T in systems, not while building. A project file that is not TOML, or a merged table that does not read as T, keeps the user’s value and is one of Settings::problems.

use rig_harness::prelude::*;
use serde::Deserialize;

/// `[large-change]`, which a project may tighten.
#[derive(Resource, Deserialize, Default)]
#[serde(default, deny_unknown_fields)]
struct Limits {
    lines: usize,
}

let mut app = App::new();
app.insert_resource(Settings::from_toml("[large-change]\nlines = 400"));
app.add_project_setting::<Limits>("large-change");
assert_eq!(app.world().resource::<Limits>().lines, 400);

Dyn Compatibility

This trait is not dyn compatible.

In older versions of Rust, dyn compatibility was called "object safety".

Implementors

impl AppSettingsExt for App