Maximkaaa
Change galileo-egui initializer to a builder pattern so native/web options can be specified.
Thanks for making galileo! I'm using it for an upcoming project, and I need the ability to specify native and web options for eframe. This was my attempt at changing the galileo-egui initializer to use a builder pattern, so it's more customizable. Curious what you think! Open to other ideas
Before
galileo_egui::init_with_app(Box::new(|cc| {
Ok(Box::new(App::new(map, layer, cc, handler)))
}))
.expect("failed to initialize");
After
galileo_egui::InitBuilder::new(map)
.with_handlers([Box::new(handler) as Box<dyn UserEventHandler>])
.with_app_builder(|egui_map_state| Box::new(App::new(egui_map_state, layer)))
.with_native_options(<NATIVE_OPTIONS>)
.init()
.expect("failed to initialize");
Hi, Corey. I do agree that the way you implemented it is more convenient and customizable. But the sole purpose of the init module in galileo-egui crate is to provide a simple way to initialize map in the galileo example in a cross-platform way. I doubt very much that any real application would need such a structure to bootstrap the application. I was going to write this in the documentation for the module, but slacked on it...
To tell the truth, I cannot even imagine a useful initialization builder structure for both Wasm and native at the same time. For Wasm you would usually want to set a DOM container for your application, load fonts though ajax, configure the map to limit in-memory caches. For native you need to set up FS caches, read data and configs from disc etc. It is usually just much easier to have two separate crates for those two targets that do all the initialization for the given platform, and then call you app code from your app's core crate.
Having said that, I'm open for discussion if you have some use case in mind that would make sense for a general-case application library.
For native you need to set up FS caches, read data and configs from disc etc. It is usually just much easier to have two separate crates for those two targets that do all the initialization for the given platform, and then call you app code from your app's core crate.
If a user of galileo (like myself) is working on a cross-platform crate, then specifying the options is straightforward. Having two separate crates would be much more complicated.
let builder = galileo_egui::InitBuilder::new(map)
.with_handlers([Box::new(handler) as Box<dyn UserEventHandler>])
.with_app_builder(|egui_map_state| Box::new(App::new(egui_map_state, layer)));
#[cfg(not(target_arch = "wasm32"))]
{
builder = builder.with_native_options(<NATIVE_OPTIONS>);
}
#[cfg(target_arch = "wasm32")]
{
builder = builder.with_web_options(<WEB_OPTIONS>);
}
builder.init().expect("failed to initialize");
My main goal with this is to specify some of the eframe::WebOptions and eframe::NativeOptions options, instead of them being hardcoded to specific values in the galileo crate.
After thinking about this for a while, I tend to agree, that since this API is provided by the library, it should be convenient, even if it will only be used for simple demo/test applications. So, if you correct the problems found by the CI, we can merge this PR.
The wasm issue should be resolved if you merge the current main in.
After thinking about this for a while, I tend to agree, that since this API is provided by the library, it should be convenient, even if it will only be used for simple demo/test applications. So, if you correct the problems found by the CI, we can merge this PR.
The
wasmissue should be resolved if you merge the current main in.
Yay! I'll do this now
@Maximkaaa Pushed the last change hopefully. Can you run the PR for CI? Also is there a reason why you have that setting on this repo?
Never looked into the settings for this. Changed it to be more permissive, so CI should start automatically now for most users.